I've replaced a few large legacy systems over the years and I disagree with most of the points mentioned in the link. The only way guaranteed to work is to run the old system concurrently with the new system with live inputs and compare results for a trial period and fixing discrepancies as they arise. Only when there is 100% behavioral/data fidelity with the old system can a switchover to the new system occur.

I'm not aware of the formal Design Pattern name, but a google search yielded this blog post on the subject: https://medium.com/@sahayneeta72/parallel-run-strategy-7ff64...

Coincidentally this is the same strategy github employed when verifying libgit2: https://github.blog/engineering/engineering-principles/move-...

▲

grahamplace 3 days ago | parent | next [-]

I’ve seen Martin Fowler call something like what you’re describing the Strangler Fig pattern

https://martinfowler.com/bliki/StranglerFigApplication.html

▲

asplake 3 days ago | parent | prev | next [-]

Better still, lots of mini-switchovers. I rolled out a bank’s p&l system for bonds that way. Trading book by trading book, those with simpler instruments first, more complex ones later. We finished ahead of schedule!

▲

sciurus 3 days ago | parent | prev [-]

You're assuming the "legacy" system is being replaced by a new one, which isn't the scenario being described in the link or the book. They cover approaches for continuing to safely evolve the legacy (i.e. untested) system.

	▲	sublimefire 2 days ago \| parent [-]
		Rewriting the legacy system is one of the valid paths to maintain it. There can be multiple reasons to do that like operational risk which cannot be mitigated, maintenance overhead, risk related to the existing dependencies of the system.