Legacy modernisation

The instinct is to rewrite, and it is usually wrong. A rewrite means reproducing behaviour nobody has documented, for a system that must keep running throughout, while the old one continues to change because the business has not stopped. Teams that attempt it spend eighteen months building toward a switchover date that keeps moving, and the project is cancelled not because the new system was bad but because it never reached parity with a moving target.

The alternative is to strangle it. New functionality is built alongside the old system behind a facade that routes each request to whichever side owns it, and one capability at a time moves across. Every step is independently valuable and independently reversible, the business keeps working throughout, and if priorities change halfway you are left with a partially modernised system rather than eighteen months of nothing. It is slower on paper and it is the version that finishes.

Data is the part that is always underestimated. Two decades of records contain values that no longer mean what the column name says, dates stored as text in three formats, and rows that only make sense if you know about a policy change in 2011. Migrating that is not a script; it is an archaeology exercise followed by a reconciliation that has to balance to the penny, and it should start long before anyone plans a cutover date.