Is waterfall the only option?
Alternative patterns for successful legacy migrations.

Legacy system migrations are complex and risky in nature. The following four dimensions provide a foundation to build upon to weather them successfully.



Steve Hauman - {Sponsoring} Partner - Core System Transformation - Deloitte

Kamil Samanci - Manager - Core System Transformation - Deloitte

Joachim Sammer - Manager - Technology & Architecture - Deloitte

Published on 4 February 2020

Share this article


Legacy system migrations are some of the most complex projects that an organization can undertake. Based on market evidence, a significant percentage of legacy migrations fails – regardless of industry and size of organization. What are the reasons for this?

Most large-scale migrations use phase-gated waterfall approaches, which lock in key product, design and technology decisions before the initiative has even started. Traditionally, organizations tend to select a single path to success, but this strategy can lead to failure. In today’s digital and ever changing ecosystems, it would be hubris to expect that we can define all relevant and detailed requirements for a multi-year project upfront. In addition, replacing years of accumulated complexity debt across an intertwined systems landscape forces an organization to repay this debt as part of a migration.

How can organizations avoid expensive migration and modernization meltdowns? The following four dimensions provide a foundation upon which to build.

Assess iterative options

A core system migration is more than just replacing a central system of records. In most organizations, the core system interfaces with dozens if not hundreds of other systems. If these integrations were loosely coupled and simple, this would not be a fearsome proposition. Too often, this is not the case and integration architectures have become Gordian Knots over time.

What are the chances of undoing this knot with the help of a phase-gated waterfall program? A top 10 global investment management firm decided not to try their luck. Instead, they opted for an iterative approach to modernise their architecture, which they presented at a global technology conference. They used the so-called “strangler fig” pattern to dry out the legacy swamp and migrate functionality step-by-step to a modern application ecosystem.

Review your methodology

Most organizations have some experience with agile teams, but at this scale and complexity, relying on team-level agile like Scrum alone will likely result in a goat rodeo. However, there are existing frameworks that scale lean and agile for larger organizations and bigger challenges. Combining lean start-up, agile and DevOps, the Scaled Agile Framework (SAFe), for instance, has proven to be successful for numerous large companies across a range of industries.

Organizations have to acknowledge that they will have to deal with uncertainty, the amount of which depends on the levels of complexity debt hidden in their legacy landscape.

Hence, choosing a pragmatic path to modernisation will reduce risks. In the phase-gate world of large projects, organizations tend to add scope to maximise project value. However, this additional value only materializes if the organization delivers the project successfully.

Customer centricity, design thinking and minimal viable products (MVP) enable you to build and migrate what customers need now and not what you have built in the past, or what someone believes your organization might need in the future. Furthermore, smaller and shorter projects have a much better chance to succeed.

Update your architecture approach

Changing the way we manage and structure application modernizations is one dimension; the second is to address how we think about architecture.

Do not build for posterity

Organizations built legacy systems to last, which holds them back in the digital age. In today’s fast-changing markets, evolutionary architecture is becoming increasingly important. At some point, you will replace every system. Therefore, every system needs to be designed in a way that will allow its cost-effective demise when its time has come.

Consider migration patterns

Design patterns have been a constant in software development since the mid-1990s. They are proven technology approaches, saving time and reducing risks. The same is true for migration patterns, but sometimes organizations omit to consider them when they review possible modernization routes.

How do organizations know that they have validated all available options for a migration? A first step is to ensure candid discussions take place about the different options and that the impacted technology teams are included early on.

One proven migration pattern is application strangulation, also known as the strangler fig pattern. The name refers to a tropical fig tree that grows on a host tree. Its roots slowly and surely cover the host, eventually causing its death. In this way, iterative releases of new functionality replace the legacy solution over time. Once all required functionality is available in the new system, the old one can be decommissioned.

Insist on early integration

Early integration facilitates learning and provides quicker feedback if an end-to-end solution is working. Until we can see working and integrated components, we can only guess and hope that we will meet our commitments. This is why agile and DevOps practices like measuring progress by working software and continuous integration have become so widely used over the last decade.

Automation, automation, automation

Not only does automation improve efficiency, it also fosters consistency and standardization of processes and best practices. Organizations that automate processes throughout the software development life cycle can see clear productivity gains and quality improvements.

Make sure your organization is ready

The following two points can easily be missed when starting a legacy migration.

The best outcomes are produced by motivated people

Faced with frightening budgets and management scrutiny, it is easy to forget about the people who will make or break your project. Migrations are long-term initiatives executed by people. Motivated teams produce the best results and it is the responsibility of servant-leaders to create an environment where teams can shine.

Ensure teams can focus on delivery

Many processes in your organization have the capability to derail even strategic initiatives. For example, service management can be a major bottleneck if implemented without lean principles. Everyone has certainly experienced the infamous prematurely closed ticket or seen a service request with a dozen cross-team hand-overs.

The focus on standardization and cost control might not be economic, if it continuously slows down a flagship digitalization project. Every hour a developer waits to get a development environment provisioned or access to a source code repository comes at a cost. If a poorly designed process affects a team or even a complete project organization, it can be a root cause for project failure.

Instead, we can center processes on self-service functionality, keep approval queues short, design lean processes and trust our teams to do the right thing.


Organizations select waterfall approaches for their apparent simplicity and familiarity. However, no plan survives contact with the enemy. Utilising an iterative approach allows organizations to validate their outcome hypothesis continuously, reducing uncertainty and risk. Finding the right methodology and architecture approach, as well as ensuring organizational readiness, are supporting pillars for a successful legacy migration.

Share #DeloitteInsideNow


When Agile teams are not enough

The Scaled Agile framework SAFe combines Agile, Lean and DevOps into a set of principles, tangible practices and competencies, giving organisations a powerful and customisable toolkit for their transformation.

© 2021. See Terms of Use for more information. Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. Please see to learn more about our global network of member firms. The Luxembourg member firm of Deloitte Touche Tohmatsu Limited Privacy Statement notice may be found at