Modernising Legacy .NET Without a Big-Bang Rewrite

Big-bang rewrites fail more often than they succeed, and the failures are expensive: eighteen months of parallel development, a business that can't get new features while the rewrite is in flight, and a cutover date that keeps slipping because the old system did more than anyone documented.

The strangler-fig pattern avoids that trap by routing traffic incrementally new functionality goes into the new system, a routing layer sends requests to old or new depending on what's been migrated, and the legacy system shrinks module by module until there's nothing left to strangle. The business keeps shipping the whole time.

Contract testing is what makes this safe. Before touching a module, we capture its actual behaviour including the undocumented edge cases nobody remembers deciding on as a suite of contract tests run against both implementations. It turns 'does the new version behave the same?' from a guess into a build-time check.

The risk nobody warns you about is data. Legacy .NET systems often carry years of implicit business logic inside stored procedures and triggers, not just application code. We treat the database as a first-class migration target with its own strangler plan — dual-writing, reconciliation jobs, and a clear cutover point per table — rather than assuming the app-layer rewrite covers it.

Done well, a strangler migration takes longer in calendar time than a rewrite would promise on a slide, but it never puts the business in a position where it has to choose between shipping and migrating. That trade-off is almost always worth it.