Modernising live IT systems piece by piece

Everyone agrees on the rewrite and nobody can schedule it

The problem

Every engineering team can name the part of the system that is holding the roadmap back. It is usually load-bearing, poorly understood, written by people who have left, and impossible to change without breaking something else. The team has costed a replacement more than once.

The usual answer

The plan never survives the conversation with the business. A rewrite means a feature freeze, and a freeze means telling sales there is nothing new for two quarters, telling customers their requests are on hold, and betting that the new system is right first time because there is no way back. Nobody signs that. So the component stays, the workarounds accumulate, and every roadmap discussion routes around it.

How we approach it

We move it across one component at a time. The new implementation goes in behind the existing interface, and traffic shifts to it gradually while the old path stays available. Both run together long enough to compare outputs on real data, so a swap is proven before it is trusted and reversed in minutes if it is not. Each piece ships as a normal release, and each one is small enough to be reviewed and rolled back on its own.

What changes

The rebuild happens on the release schedule the team already has. No freeze, no big-bang cutover weekend, no bet on getting the whole thing right at once. Feature work continues alongside it, and customers never see the seam.