Moving an insurance ledger to AWS without stopping the business

An insurer running policy administration, claims and a transaction ledger on ageing on-premises virtualisation wanted to be on AWS. What they could not have was a maintenance window: the ledger is written to during business hours in several states, and a day of downtime is a regulatory conversation, not an inconvenience.

What we walked into

Around forty services with dependencies nobody had drawn in years, a single flat network where everything could reach everything, and a database that three separate applications wrote to directly. The first six weeks produced no migration at all. They produced a dependency map and an agreed order of moves.

Accounts before networks

We set up AWS Organizations first, because account boundaries are the only isolation that cannot be undone by a bad IAM policy later.

• Separate accounts per environment and per business domain, so claims cannot read policy data by accident
• Service Control Policies denying regions the business does not operate in, and denying anyone the ability to turn off CloudTrail
• A dedicated logging account that other accounts can write to and nothing can delete from
• A shared services account holding the Transit Gateway, DNS and the Direct Connect attachment

One hub, thirty-plus VPCs

Every workload account got its own VPC. Peering them pairwise would have been unmanageable, so everything attaches to a Transit Gateway in the shared services account, with route tables per segment.

• Production, non-production and shared services on separate Transit Gateway route tables, so non-production cannot route to production at all
• The on-premises datacentre attached at the same hub, which is what let services move one at a time rather than all at once
• Route 53 Resolver rules forwarding internal zones both directions during the overlap period

The routing was the part we spent most design time on. A loop between the on-premises network and a transit route table is easy to create and unpleasant to debug at four in the morning, so the route tables are generated from CloudFormation rather than edited by hand.

The ledger cutover

The database moved by replication, not by export. An RDS instance ran as a replica of the on-premises database for weeks while we validated row counts and checksums nightly. The cutover itself was:

• Freeze writes at the application tier for a few minutes
• Confirm replication lag at zero
• Promote the RDS instance
• Flip the internal DNS record
• Unfreeze

We rehearsed it twice against a copy of production in an isolated account before doing it for real. Both rehearsals found something. The first found an application with a hardcoded host, the second found a batch job nobody had mentioned.

Where it landed

• No business downtime at cutover. The freeze window was measured in minutes and fell outside transacting hours
• 30+ VPCs on one Transit Gateway with no routing loops in production
• About 40% lower operating cost, mostly from retiring hardware and right-sizing instances that had been provisioned for a five-year peak
• Environments now rebuild from CloudFormation, which the previous estate could not do at all

What was hard

Discovery. The technical work was ordinary; finding out what actually talked to what was not. Two services were found only because they broke in a rehearsal. Budget for that phase honestly, or the schedule discovers it for you.

What we still do

We run the platform: patching, backup verification, cost review each month, and the on-call rotation for the shared networking layer. The application teams own their own accounts.