Copying the bunny without the cancer is every legacy rewrite project challenge.

These Change Series take you through the safest and fastest way to replace a legacy system: by using a crossover system during the transition. This is a three-step process.

1. Start shipping from a crossover system, so you are effectively building one product that ships two ways.
2. Refactor your one product until you are happy, while migrating collaborating systems to use the new system.
3. Stop shipping the old system.

These same Change Series apply if you are refactoring a system in place. The teams just skip the crossover system step.

• Change Series: Ship from a Crossover System

  This change series enables features to be implemented in the new and old system without additional cost. This additionally reduces the risk of replacement project never finishing.

Once that baseline is established, the teams can take their pick of Change Series based on what they are facing. Each addresses one common design flaw, showing how to migrate the functionality without the flaw.

• Change Series: Fix Duplication

  This change series fixes duplication and semi-duplication in the old system, making it easy to understand what to move to the new system.

• Change Series: Fix Remotely Coupled Code

  This change series will allow parts you want of the old system to be moved to the new system, leaving behind the parts you don’t want.

• Change Series: Fix God Classes

  This change series guides fixing god classes in the old system to make the relevant code movable to the new system, since they tie together data that will end up in different parts of the new system.

• Change Series: Fix Procedural Utility Classes

  This change series puts together the pieces in the old system that need to be together in the new system. Procedural utility classes tie together unrelated functionality and makes it hard to build a new system.

• Change Series: Fix Complex Methods

  This change series will ensure that the new system gets the behavior of the complex method in a tidy readable way.

• Change Series: Fix Untestable Code

  This change series allows you to make untestable code become easy to test, by decreasing coupling. Low-coupling code is easier to move incrementally between systems and share between teams.

• Change Series: Advanced Testing

  This change series makes software testing provide useful feedback on company decisions not directly related to software implementation.

• Change Series: Fix Arcane Architecture Choices

  This change series will guide undoing various architecture choices that turned out to be bad ideas but are universal in the old system. This allows re-using code into a new system with a different architecture.

• Change Series: Test Challenging Dependencies

  This change series allow automatic testing for properties that usually can only be validated manually once the whole system is put together.

• Change Series: Break a Service Out of the Monolith

  This change series will extract chunks of the old system into a new service for the new system without disrupting the company.

• Change Series: Change Data Back-end

  This change series allows data to be shared between the old and new systems even while you are making the back-end optimal for the new system.