In March 2026, INSIDE ran a story about Taiwan Adventist Hospital's AWS migration — "Zero-Impact Migration Complete," "A Model for Healthcare Cloud Adoption"
Sounds smooth, right?
I was the technical consultant on that project. This isn't about the architecture diagram. It's about the moments I still remember.
First Time in a Hospital
I'd been doing cloud development for years — GCP and AWS, FastAPI, Cloud Run, the usual stack. The tech wasn't the issue
But hospitals are a completely different world. Medical data has regulatory constraints, security compliance requirements are a tier above standard enterprise, and the IT department operates on a completely different logic than a startup. Registration systems can't go down. Medical records can't go down. Clinical order systems can't go down — anything you touch carries real risk
A consulting firm brought me in as the technical executor. I could handle the cloud architecture, but the rules of the healthcare domain? That was new
This Isn't How Traditional SIs Do It
Before the rest of the story makes sense, I need to explain something
A traditional systems integrator running a project like this deploys a certified AWS engineer, budgets 3 to 6 months, brings in a team. Deep specialization in one platform, project after project of the same type
I was the opposite. Solo, touching every major cloud, most at home in GCP but expected to deliver on AWS — while running ten other projects simultaneously
How?
I used AWS Console, CloudFormation, VPC Flow Logs — the native tools — to build the architecture, debug issues, and validate connectivity. The hands-on work was mine
But at key moments, I used AI to accelerate
Mid-debug on a VPN issue, I needed to quickly cross-check Fortinet and AWS Phase 2 parameters — instead of flipping through three documents, I dropped the config into Claude and had the answer in ten seconds
After each incident, I had AI help me structure the troubleshooting process into a formal SOP. Those SOPs eventually got handed over to the hospital's IT team
The difference: traditional SIs carry knowledge in people's heads. When someone leaves, that knowledge walks out the door. I captured every lesson in systems — transferable, reusable
Four Organizations, Three Languages
The real complexity here wasn't technical. It was human
- Hospital IT team: Keeping registration, medical records, and clinical order systems running at all times. They agreed to allocate time for the project — but their daily work wasn't going to wait
- AWS: Providing architecture guidance and technical support. This project was also a meaningful milestone for their Taiwan region team
- RiverMeadow (the migration tool vendor): A global team spanning the Americas, Europe, and Asia. The engineer we worked with most was in the US, spoke English, and could only meet during our evening hours
- Us (the consulting team): Responsible for threading all three of those groups together and making things happen
In a single meeting you'd have people speaking Mandarin, people speaking English, someone in the hospital server room on their phone, someone in an American living room. Different time zones, different languages, different definitions of "done"
Just getting all four parties to agree on a meeting time could eat a full week
The Tunnel That Wouldn't Open
The project needed a VPN tunnel — hospital network to AWS
Should be simple. Configure the firewall, establish IPSec, validate the connection. A textbook page
But the hospital's existing firewall needed low-level configuration changes, and that device was carrying the hospital's entire daily traffic. The vendor's review process was thorough — touching that device carried real risk
But the project couldn't wait. Technically everything else was ready. That one tunnel just wouldn't open
The team decided to bring in a different firewall device to build the VPN, bypassing the original bottleneck. After the swap, it was up in days
That one stuck with me — sometimes the fix to a technical problem isn't technical. It's being willing to take a different path
Two Hours of Late-Night Debugging
We scheduled an international call to officially kick off the migration run. US engineers, hospital IT, our whole team — everyone online
Once the migration tool started, the connection kept dropping. Packets were getting lost, throughput was all over the place
We started triaging. Checked firewall logs — nothing obvious. Checked AWS traffic analysis — traffic was arriving but not getting responses. Checked the routing table — looked correct on paper
I was talking through it with everyone on the call while cross-referencing AWS VPC Flow Logs and Reachability Analyzer on my own
Midway through, I threw the current findings into Claude and asked "what directions am I missing" — it surfaced one I hadn't considered: device-level access control. That turned out to be the right thread
Almost two hours in. We were close to opening an AWS support ticket
The answer turned out to be something we weren't even looking at — a piece of the hospital's internal infrastructure was silently dropping our traffic. No error message, no log entry. Just gone
One configuration change — ping came back immediately. Two hours of debugging, thirty seconds to fix
The debugging itself was standard engineering work. But in a high-pressure international call, having something that quickly surfaces your blind spots — that saves real time
"How Do I Prove to My Boss That It's Done?"
After one of the later calls, everyone else dropped off and the hospital's IT point of contact stayed on with the US engineer. He asked a question:
"How do we prove the migration was successful? What do I bring to my manager to say — this is finished?"
That question doesn't appear in any technical document. No SOP covers how to show a non-technical manager what a cloud migration actually produced
But that was what he actually needed. Not just to move the machines over. He needed to be able to walk into his director's office and hand over something concrete
The US engineer knew exactly what to do — pulled up the migration tool's reporting dashboard, showed the completion percentages, the timeline view, the PDF export
That moment taught me something: finishing the technical work isn't the same as finishing the delivery. The client doesn't just need "it's done" — they need proof they can bring to their boss
Since then, every time I close a project, I ask myself first: "How does the client explain this to their manager?"
Months vs. Hours
Looking back, the actual technical configuration work took maybe a few weeks. But from kickoff to close, the project ran for months
The time in between was all waiting. But every wait had a reason
The hospital's IT team wasn't just serving our project. They were running registration, medical records, handling hundreds of users' daily issues. Carving out half a day to help us test meant pushing aside their real work. You can't rush that — their daily priorities outrank your POC
Firewall changes required vendor review. That device carried the entire hospital's network traffic. Any modification could affect outpatient operations. The review process was slow, but it existed to protect patients, not to create bureaucracy
International meetings required timezone alignment. The US engineer's morning was our midnight. Hospital IT could only meet during business hours. The window where all three parties were available might be one or two hours per week
None of these waits were anyone being lazy. Each organization had its own rhythm and constraints. Add them together, and the timeline measured in months
This was something I didn't understand before this project. In software, I controlled the timeline. In healthcare, every move you make touches real operational risk. You can't move fast — and you shouldn't
AI helped with documentation throughout — after each call, I'd drop the recording in and have a structured summary in minutes: who said what, what was decided, what was still open
Mixed-language meetings (Mandarin and English throughout) were especially useful to process this way. Manual notes for one call took an hour; AI did it in minutes. The final project report was assembled from those records — saved roughly two days of writeup work
But AI can't chase people for you. Can't schedule meetings. Can't align four organizations' priorities. That part still runs on humans
What Actually Happened at the End
After the migration, we put together a closure report for the hospital — before-and-after comparison, validation results, system health status — so the IT contact could walk into his manager's office with something concrete
The hospital's IT director said something at project close (quoted in the INSIDE coverage): "For frontline medical and administrative staff, the best feedback is no feedback at all"
Frontline clinical staff never noticed anything out of the ordinary. Registration, medical records, clinics — everything kept running
On the drive home, I wasn't thinking about the architecture. I was thinking about that earlier moment when the IT contact asked "how do I explain this to my boss"
The technical side, I handled. But learning to stand where the client stands — to help them turn results into something they can actually present — that's the most important thing I took from this project
Full INSIDE coverage: Taiwan Adventist Hospital completes "zero-impact" AWS migration