Built for Handover: How a Regulated Insurer Moved from AWS to Azure in 30 Days

The situation

A regulated medical liability insurer had begun a platform modernization on AWS under a prior contractor. The microservices ran on Amazon EKS, with Amazon RDS for PostgreSQL behind them, AWS WAF in front, Route 53 for DNS, Amazon S3 for object storage, AWS IAM for access control, and a site-to-site tunnel into the insurer's on-premises environment. The architecture worked. The ownership model did not.

Internally, the insurer was a Microsoft organization. Operations, identity, productivity tooling, internal applications, and the broader technology footprint were all standardized on Microsoft. The AWS platform sat outside that perimeter, requiring a specialty AWS partner to operate and evolve it.

The platform worked. The ownership model did not.

When ExeQut took over the program, we recognized this gap early. The strategic question was not whether the platform could run on AWS; it was whether the client's own people could own it long term without retaining specialty-cloud expertise indefinitely.

The challenge

1. Resolve the long-term ownership gap between an AWS-hosted platform and a Microsoft-standardized internal organization.
2. Avoid disruption to a regulated insurance workload during migration, including the production database.
3. Preserve the modernization investment already made: no regression on architecture, security posture, or release discipline.
4. Hand the platform to the client's internal operations team in a state they could confidently own from day one.
5. Keep total migration time short enough to be acceptable to executive sponsors and program governance.

The approach

The operating model

We embedded with the client's internal operations team from the start of the migration window. The cadence was simple: short daily working sessions, weekly governance touchpoints with program leadership, and continuous knowledge transfer woven into the migration work itself rather than reserved for a separate training phase at the end.

This mattered because the deliverable was not just the Azure platform; it was an internal operations team that could own that platform on day one.

The technical architecture call: EKS to Azure Container Apps

The most consequential architectural decision was on the destination side. The AWS environment ran on Amazon EKS, a fully featured Kubernetes service that is powerful and operationally heavy. A like-for-like move to Azure Kubernetes Service was the obvious option. The obvious option was wrong for this client.

The internal operations team was lean. The microservices were already containerized as Docker images. The control-plane complexity of Kubernetes was not earning its keep against the operational burden it imposed on a small operations group that would be running this platform for years.

We chose Azure Container Apps as the destination runtime. Container Apps gave us:

• A managed, serverless container platform with built-in revisions, scaling, and ingress
• A dramatically smaller operational surface for the ops team to learn and own
• Compatibility with the existing Docker-based packaging, with no application rework required

The destination runtime was chosen for the team that would operate it, not the team that built it.

Identity, networking, and the on-premises tunnel

We aligned the platform with the insurer's Microsoft-centric footprint at every layer. AWS IAM mapped to Entra ID and Azure role-based access control. AWS WAF was rebuilt as Azure WAF with equivalent rule coverage. Route 53 records moved to Azure DNS. S3 buckets moved to Azure Blob Storage with equivalent access patterns. The site-to-site tunnel into the on-premises environment was rebuilt in Azure with the same connectivity contract as the AWS implementation, so the on-premises systems experienced no change in their interface to the platform.

Infrastructure as code as the migration backbone

When ExeQut took over the AWS work earlier in the program, we made a deliberate choice to declare every AWS resource as Terraform from day one, before any Azure migration was on the table. That choice paid off when the strategic direction changed.

By the time the Azure decision was made, every resource was already declared, versioned, and reproducible. The migration became a parallel-environment exercise rather than an archaeology project. We could stand up Azure resources with confidence, compare them against the AWS baseline, and reason about parity at the code level rather than by clicking through two consoles.

Pipelines ran in GitLab CI, the client's existing standard, which kept the developer experience continuous across the cloud transition.

Build for client ownership, not vendor lock-in. The Terraform we wrote on AWS is the same discipline that let us leave AWS in 30 days.

Deployment and the two-minute cutover

The cutover plan was scripted end to end, including the PostgreSQL migration. We rehearsed the sequence repeatedly in non-production environments before the production cut. On cutover day, the platform experienced two minutes of downtime. The database transition was scripted, replayed, validated, and switched over within that window. There was no extended maintenance period and no degraded-state interim.

For a regulated insurance workload, two minutes is the difference between a routine change and a reportable incident. We treated it as the bar.

The outcome

The platform now runs on Azure, fully consistent with the rest of the client's technology footprint. The internal operations team owns it end to end. There is no specialty-cloud dependency, no perpetual outside operator, and no architectural debt accumulated during the move.

Specifically:

• The full microservices platform was migrated from AWS to Azure within a 30-day window that included training the client's internal operations team.
• Cutover downtime was 2 minutes, with the database transition fully scripted.
• The Azure environment is declared in the same Terraform discipline that ran the AWS environment, so the client owns reproducible infrastructure, not a snowflake.
• Identity, networking, WAF, DNS, and storage all map cleanly onto the client's Microsoft-standardized stack, fitting inside the operating model the rest of the organization already runs.
• Operational sovereignty was the goal, and the goal was met. The client can evolve, scale, and audit the platform with their own people.

What we took from it

A few generalizable lessons for federal and regulated program leaders weighing a similar move:

1. Decide ownership before you decide architecture. The right cloud is the one your people can run. A platform that requires a specialty partner forever is not a finished modernization; it is a recurring procurement.
2. Treat infrastructure as code as optionality insurance. Writing IaC from day one is not just discipline for your current environment; it is the option to change clouds, regions, or providers later without an excavation project. The Terraform foundation established on AWS is what made the Azure migration measurable in weeks.
3. Match the runtime to the operator, not the architect. A migration is a chance to right-size operational complexity. Kubernetes is the right answer for some teams and the wrong answer for others. Choose the destination runtime based on the people who will own it on day 366, not day 1.
4. Script the cutover, including the database. Two minutes of downtime is not luck; it is rehearsal. If the runbook is not idempotent and replayable in a lower environment, it is not ready for production.
5. Embed knowledge transfer into the work, not after it. Training delivered after migration is training on a system the operators did not help build. Training delivered during migration is just delivery, done well.