Modernising a legacy platform without a big-bang rewrite
The instinct, when you inherit a platform of dozens of services accreted over a decade, is to propose a rewrite. It almost always fails, not for technical reasons, but because a rewrite freezes feature delivery while the business keeps moving, and the old system keeps changing underneath you.
I approach it differently. A few principles I keep coming back to:
Map before you move. You cannot sequence a migration you don’t understand. Service topology, the real call chains, which databases are actually coupled: this gets reverse-engineered into living documentation first. That map is what lets you cut the estate into a delivery sequence instead of a wish.
Phase it, and keep both systems honest. New and old run side by side. Change data capture (logical replication moving data continuously) means the target is never stale, so you can cut over a slice at a time and roll back a slice at a time. No weekend where everything changes at once.
Make the risky steps reversible. Every step that mutates shared state should know how to undo itself. This is the same instinct whether it’s a database migration or a deploy pipeline: design the compensating action alongside the forward one, so partial failure is safe rather than catastrophic.
Kill rented complexity where it pays. A sprawling estate accumulates vendor spend and coordination cost. Some of the highest-leverage work is consolidation: fewer services, fewer moving vendors, a schema that one person can reason about.
Document as you go, for humans and agents. Migration briefs, dependency maps, reverse-engineered specs: these aren’t overhead, they’re what reduces onboarding time and fragmentation while the team churns around a big change.
None of this is glamorous. But “the platform got quietly cheaper, more reliable, and easier to change, and we never stopped shipping” is a better outcome than a heroic rewrite that slips a year.
I take on remote consulting for exactly this kind of work, platform modernisation, migration architecture, and backend reliability. Get in touch.