Moving a live insurance platform to AWS inside one short window
- Organisation
- iLyF — Easy, Instant Insurances
- Role
- Migration lead — planning, cutover and post-migration tuning
- Period
- Malaysia
A production cutover on a product where downtime is not an inconvenience — someone buying cover at 9pm may be driving at 9:05.
- planned downtime, start to finish
- Under 30 minplanned downtime, start to finish
- service stayed available through the move
- No outageservice stayed available through the move
- faster admin page loads afterwards
- 50–70%faster admin page loads afterwards
- API responses at peak load
- Sub-2-secondAPI responses at peak load
How the system actually worked
Context
The platform had outgrown where it was running. Admin pages were slow enough that the operations team had built workarounds, and API timeouts were appearing at traffic peaks — on a product where a timeout during checkout is a customer who does not come back.
What was actually needed
A migration to AWS that customers would not notice. Motor insurance carries a constraint most products do not: cover has to be live the moment someone pays for it, so there is no acceptable maintenance weekend.
What I did
I planned and ran the cutover — the sequencing, the rollback criteria, a full dry run against a cloned environment, the write freeze, the final delta sync, the DNS and configuration switch, and the smoke tests that decided whether we committed or reversed. Afterwards I stayed on the performance work: query optimisation, caching and load balancing, until the API sat under two seconds at peak.
How I ran it with the team
Every person had a written role for the window and a single explicit go/no-go call at each checkpoint. That sounds heavy for a team of this size, and it is exactly what stops a migration turning into five people improvising in a group chat at midnight. The dry run was as much about rehearsing the people as the systems.
Decisions that mattered
Rehearsing the rollback as carefully as the migration itself. The dry run was not there to prove the migration worked — it was there to prove we could undo it. That is what made a short window acceptable to the business rather than terrifying.
What changed
Under half an hour of planned downtime, no loss of service across the move, and admin page loads well over half again faster once the post-migration tuning landed. The API timeout complaints stopped.
The insight I kept
Downtime is a budget you spend, not an accident you suffer. Once the window was written down as a number and we worked backwards from it, every decision about what to sync, what to freeze and what to defer had an obvious right answer.
Stack & practices
- EC2
- S3
- VPC
- RDS
- Lambda
- CloudFormation
- IAM
- CloudWatch