Choosing a cloud architecture you will not regret in two years
Most cloud regret is not a technology problem. It is a sizing problem, teams adopting the architecture of a company ten times their size.
Read article →Every legacy system was once someone's modern system. It accumulated behaviour because the business needed that behaviour, and much of that behaviour is undocumented, which is precisely why replacing it wholesale is so dangerous.
Why big-bang rewrites fail
They fail for structural reasons that have little to do with team quality:
- The old system keeps changing, because the business does not pause for your project.
- Undocumented behaviour is discovered at cutover, when it is most expensive.
- No value ships until everything ships, so the project has no way to prove itself.
- Support for two systems doubles the operational load during the longest, hardest phase.
The strangler pattern, concretely
Put a routing layer in front of the legacy system. Move one capability at a time behind it. Each move is independently valuable, independently reversible, and independently verifiable. Sequence by a simple rule: highest pain, lowest coupling, first.
The goal is not to finish the migration. The goal is to be better off after every individual step, including the ones you never get around to.
Characterisation tests before changes
Before touching a component, write tests that capture what it currently does, including the behaviour that looks like a bug. Those tests are not describing correct behaviour; they are describing current behaviour, and something downstream almost certainly depends on it. Deciding which quirks to preserve is a business conversation, not a technical one.
Data migration is the real project
Teams consistently underestimate this. Legacy data carries a decade of workarounds: sentinel values, overloaded columns, records that violate constraints the schema claims to enforce. Profile the data early. Run migrations repeatedly against production copies. Build reconciliation reports that prove old and new agree, and keep running them after cutover.
Keep a rollback that you have actually tested
Run both systems in parallel and compare outputs before you switch traffic. Keep the old path available and warm until the new one has survived a full business cycle, month-end, quarter-end, whatever your peak is. A rollback plan nobody has rehearsed is not a rollback plan.