Legacy System Replacement Map

The idea behind it

The strangler fig pattern is a way to replace a legacy system gradually instead of in one big cut-over. Martin Fowler named it in 2004, after the strangler fig vine, which grows around a host tree until the host dies and the fig stands on its own. In software, new components are built beside the old system. A routing layer, often called a facade, sends each piece of traffic to either the old or the new code. Over time more traffic moves to the new components, and the old ones are switched off one at a time.

The method depends on finding seams. Michael Feathers, in Working Effectively with Legacy Code, defined a seam as a place where behavior can change without editing the code around it. A migration needs a broader view than code alone. A data entity, a business process, an integration such as an API or file feed, and a user journey can each be a seam. Each seam is a unit that can be moved, tested in parallel and rolled back on its own. The hard part is shared state. Two seams that read and write the same database tables cannot move independently until that data is split or kept in sync. The pattern also requires discipline at the end: an old component that is never retired leaves two systems to run instead of one.

What's inside

• A table of four seam types (data, process, integration and UI), each with a definition, a key question and examples.
• A seam dependency map: each seam's type, owner, size, what it depends on, what depends on it, shared state, cut-over risk and sequence.
• Seven cut-over steps, from identifying seams to retiring the old component.
• A cut-over waves table: Waves 1 to 5, with target start and end dates and a go/no-go owner for each.
• A rollback plan with five questions to answer before each cut-over.
• Five common failure modes, such as seams that are too large and shared databases left unaddressed.
• The PowerPoint version has eight slides: title, seam types, seam inventory, dependency map, cut-over steps, cut-over waves, rollback plan and failure modes.

Format: PDF (4 pages) and PowerPoint file.

A look inside

Pages 1 and 2 of 4 of the PDF. Select an image to enlarge it.

Who uses it

• Enterprise architects, to break a legacy system into pieces that can move one at a time and to show the order on one page.
• Modernization program leads, to plan migration waves with a go/no-go owner and target dates for each.
• Engineering managers, to size each seam so a team can deliver it in weeks rather than months.
• Operations and service owners, to agree the rollback trigger, window and decision-maker before each cut-over.

When to use it

• A rewrite of a core system has been proposed as a single go-live and the risk of that date is too high.
• A legacy platform is losing vendor support but cannot be switched off without moving many integrations.
• A modernization program has stalled because every piece seems to depend on every other piece.
• Two teams want to migrate different functions that turn out to share the same database tables.
• An earlier migration left the old and new systems both running with no retirement date.

How to use it

Use it to plan an incremental modernization, filling in the sequence column last, once all dependencies are mapped.

1. List every candidate seam in the Seam Dependency Map, classifying each as Data, Process, Integration or UI using the definitions and key questions in the What Is a Seam table.
2. Split any seam that would take longer than four to eight weeks to migrate.
3. Fill in Depends On and Depended On By for each seam, then mark Shared State as Yes for any seam that shares a table or in-memory state with another.
4. Set a data synchronization strategy for every seam flagged with shared state, and rate the Cut-Over Risk as H, M or L.
5. Fill in the Sequence column last, starting with seams that have no dependencies and low risk, then group them into Waves 1 to 5 with a go/no-go owner for each.
6. Build the strangler facade before the first seam moves, then run old and new in parallel for at least one production cycle per seam.
7. Complete the Rollback Plan questions for each seam before its cut-over, and set a retirement date for the old component on the day of cut-over.

You leave with: A sequenced list of seams with their dependencies, shared state and risk marked, and a written rollback plan for each cut-over.

Where it goes wrong

• Seams sized so large that each one becomes a smaller big-bang migration; the canvas caps them at four to eight weeks.
• Sequencing before dependencies and shared databases are mapped, which puts tightly coupled seams in separate waves.
• Skipping the routing facade, which removes the ability to run old and new side by side and to roll back.
• Moving the process or code but leaving it reading the legacy data model, so nothing has actually been migrated.

Get the canvas

It is free. Enter your work email and we send the download link.

Questions

Read more on this

• Strangler Fig Pattern
• Replacing a core system in a regulated industry follows a different playbook