Legacy System Modernisation with Zero Downtime: A Practical Playbook
Big-bang rewrites fail. The strangler-fig pattern with a typed event bus and parallel-run verification lets you ship modernised functionality every two weeks without taking the production system down.
Legacy systems are not replaced; they are unbundled, modernised in slices, and retired one bounded context at a time. The risk of a big-bang rewrite is well documented - most fail or run years late. The strangler-fig pattern, with a typed event bus and parallel-run verification, lets you ship modernised functionality every two weeks without taking the production system down. This article describes how MIT-DEV runs that playbook in practice.
Why Big-Bang Rewrites Fail
- The new system must implement every quirk of the old system to take traffic
- The old system keeps accumulating features during the rewrite - a moving target
- The cutover is high-risk: rollback path is rarely tested at production volume
- Business value lands at the end of a multi-year programme; budget and patience run out first
Martin Fowler's Strangler Fig Application writes up the alternative: build the new system around the old, redirect traffic slice by slice, retire the old one when the last slice is migrated. The system is always in production; value lands every sprint.
The Zero-Downtime Playbook
Step 1 - Map the Bounded Contexts
Identify the natural seams in the legacy system: Auth, Billing, Inventory, Reporting, Notifications. Rank them by business value, risk, and dependency. The first module to migrate is rarely the most central one - it is the one that proves the migration pattern with the lowest blast radius.
Step 2 - Introduce the Event Bus
Every state change in the legacy system is mirrored as a typed event on a message bus. The new system subscribes, reads its own materialised view, and writes back through the bus. The legacy DB remains the source of truth until the cutover.
Step 3 - Build the First Module
Implement the new module on a modern stack with the API contract the rest of the system will eventually consume. Internal users see no difference; the API is what changes.
Step 4 - Run in Parallel
For two to four weeks, every operation goes to both systems. Outputs are compared; any divergence is a defect to fix. Only when divergence is zero do we cut traffic over.
Step 5 - Cut Over Behind a Feature Flag
Traffic shifts 1% → 10% → 50% → 100% over hours or days, depending on volume. Rollback is a feature-flag toggle, not a deploy. The legacy code stays in place, dark, for one to two release cycles before retirement.
Step 6 - Retire and Repeat
When the new module has run alone at 100% for two weeks without incident, the legacy code is removed, its DB tables are archived, and we start the next module on the same pattern.
What This Looks Like in Practice
A regulated lender ran on a Delphi/Firebird system from 2008. The system worked, but the regulator's reporting requirements had grown and the original developer had retired. We mapped seven bounded contexts, started with Reporting (the lowest-risk, regulator-facing module), and migrated to a Python/Postgres stack. Reporting was live in 10 weeks. Each subsequent module took six to eight weeks. The Delphi system was retired 14 months after kick-off, with zero downtime, zero data loss, and four regulator audits passed during the migration.
MIT-DEV Track Record
- Zero unplanned downtime across modernisation projects in our portfolio
- Stack experience across Delphi/Firebird, classic ASP, .NET Framework, PHP 5, Java EE, Cobol
- Module-by-module retirement in 6–8 weeks per context after the first one is in production
- Parallel-run verification on every cutover, with divergence tracked in CI
Frequently Asked Questions
How long does a typical modernisation take? For a system of moderate complexity (5–8 bounded contexts), 12–18 months from kick-off to full retirement. The first module is in production within 8–12 weeks; the customer sees value continuously from that point.
What about the data? Historical data is migrated module-by-module, validated against the legacy source. Live data flows through the event bus and is reconciled in real time.
Can the legacy team continue maintaining the old system in parallel? Yes, and that is usually the right pattern. The legacy team keeps the lights on; the modernisation team builds the replacements; both teams meet weekly to coordinate.
What if the legacy system has no API? We instrument the database with change-data-capture (CDC). The legacy app does not need to change; we read its commit log directly into the event bus.
Ready to Plan Your Modernisation?
Book a modernisation Discovery - we will map your bounded contexts, rank by risk, and propose the first module to migrate.