This pattern is part of "Patterns of Legacy Displacement"

Divert the Flow

Divert key business activities and processes away from legacy first

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.

A very common challenge when replacing legacy systems is the fact they support key cross cutting business activities, such as reporting, auditing or providing key business metrics. These types of requirements are often cited as a critical need to provide full synchronization between the new solution and the legacy system, which in turn leads to them being one of the last things to get migrated. This synchronization can be highly complex to design and implement successfully. We've seen multiple organizations where the legacy ends up remaining in place precisely because this is such tricky area to get right.

As an alternative approach we instead can "divert the flow" of these key activities to the new solution at the very beginning, with the various legacy systems acting as data sources for this new solution. While it could be argued this creates extra throw away work (the temporary integration with legacy) we see it as akin to diverting a river when building a dam.

Engineers divert a river to create a safe and secure environment for building the dam, once complete these diversions might then be surplus to requirements but few would argue they were a waste of money or unnecessary. In the same way if we can build new solutions for things like reporting first we can make the overall legacy migration safer and less risky by removing the need to support legacy reporting mechanisms. While not only useful for cross cutting business processes we find this pattern most useful in these situations as it provides a way to break the coupling between the individual 'delivery slices' and these processes.