Lessons learned migrating a years-old monolith to microservices on AWS
By Floppai Engineering
The hard part of a migration is rarely the code. It is sequencing, data, and keeping the lights on while you rebuild the engine.
Every monolith migration starts with the same optimistic diagram: a tidy set of boxes with arrows between them. Reality is messier. The monolith works — that is the problem. It carries years of business rules that nobody fully remembers, and customers depend on it every minute.
Here are the lessons that survived contact with production.
Migrate by capability, not by table
The most common failure is slicing services along the existing database schema. You end up with distributed monolith: services that cannot deploy independently because they share data. Slice along business capabilities instead, and let each service own its data.
Use the strangler-fig pattern: route traffic incrementally, capability by capability, with the monolith and the new services running side by side until the old path is dead code.
Data migration is the project
Teams budget for rewriting code and forget that moving data — consistently, without downtime, with a rollback path — is where the months go. Dual-write, backfill, reconcile, then cut over. Measure reconciliation continuously; do not trust a one-off check.
On AWS this usually means a careful dance of RDS, DMS, event streams and idempotent consumers. None of it is glamorous. All of it is where projects succeed or fail.