Legacy software modernisation

• //Reading the system and writing down how it actually behaves today
• //Repairing the data model, including migrations for records already stored wrongly
• //Dependency and runtime upgrades that have been deferred for years
• //Test coverage around the rules that matter, so changes stop being blind
• //Splitting apart the parts that should never have been coupled
• //Staged replacement of components, without a single high-risk launch

When the engineering answer to every request is that it is complicated. When nobody will touch a particular file. When a dependency is so old that a security patch cannot be applied.

Also before a rebuild is decided. A refactor is frequently cheaper than a rewrite, and the audit will tell you which one applies.

• //A full rewrite started in parallel. Two systems need maintaining, the new one never catches up, and budgets run out. We replace the system piece by piece while it keeps running.
• //Refactoring without tests. Nobody can prove behaviour stayed the same, so new bugs appear in production. We write tests around the current behaviour before changing anything.
• //Tidying code but keeping the data model that caused the problems. The same bugs come back. We fix the data model in staged, reversible migrations.
• //Upgrading everything at once. When something breaks, nobody knows which change caused it. We upgrade in small steps, each one deployed and verified.

We start by establishing facts: what the system does, what the data looks like, what is covered by tests and what is not. That assessment is the audit.

Then we work in small, reversible steps with the system live throughout. No parallel rewrite, no freeze on feature work unless you want one.

• //Audit first, always — refactoring a system we have not read is guesswork
• //A prioritised sequence, starting with whatever is currently causing incidents
• //Each step deployed and verified before the next begins
• //Your team involved throughout, so the knowledge stays with you