This pattern is part of “Patterns of Legacy Displacement”

Build as you mean to continue

Create your legacy replacement in the way you need to continue once it is live.

This page is a stub. We intend to fully expand it in later revisions of this material. However we are still in the middle of developing these patterns, so it's likely that patterns will be renamed, split, or merged as we continue to learn how best to frame and explain these ideas.

The business cases for legacy replacement almost always includes cheaper, faster and, more frequent releases of business requirements. Experience tells us it is simply not realistic to build towards one 'big bang' release and then expect to subsequently switch, post release, to faster more frequent updates. If the first release to production environment took a year you should expect the next one to take at least several months. This all too common failure scenario leads to frustrated business stakeholders and a failure to deliver the expected returns on investment.

To avoid this outcome we recommend building in the manner in which you need to continue. If you need improved release frequency, cheaper releases or faster changes then the only way to be sure of getting these is to build and deploy that way right from the start of any displacement effort.

Additionally very few businesses can afford a change freeze or period of (even) slower changes while a key system is replaced. Competitors won't stop adding new features and regulators can't suspend new rules just because an organization has embarked on a multiple year legacy replacement programme. Many organizations need an approach to legacy that accommodates business and technology change whilst in flight