Skip to main content
Engineering LibreTexts

7.4: Migrate Systems Incrementally

  • Page ID
    32403
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    Also Known As: Chicken Little [BS95]

    Intent Avoid complexity and risk of big-bang reengineering by deploying functionality in frequent increments.

    Problem

    When should you plan to deploy the new system?

    This problem is difficult because:

    • Projects are often planned and funded on large timescales, with “big bang” requirements specification done up front.
    • The real requirements are often only clear in hindsight. Users will resist adopting a new system that is radically different from what they are used to, especially if it does not work flawlessly from the beginning.
    • The longer you wait to deploy the new system, the longer you must wait to get user feedback.
    • You cannot deploy an incomplete system. Users do not have time to waste on incomplete solutions.

    Yet, solving this problem is feasible because:

    • You have a running system that can be extended and modified.

    Solution

    Deploy a first update of the legacy system as soon as you can, and migrate incrementally to the target system.

    Steps

    • Decompose the legacy system into parts.
    • Choose one part to tackle at a time.
    • Put tests in place for that part and the parts that depend on it.
    • Take appropriate steps to wrap, reengineer or replace the legacy component.
    • Deploy the updated component and obtain feedback.
    • Iterate.

    Tradeoffs

    Pros

    • You get user feedback early and Build Confidence.
    • You see immediately when things break.
    • Users learn the new system as it’s being built.
    • The system is always deployed.
    • The system is always being tested, so you can’t skip testing.

    Cons

    • You will have to work harder to keep the system running while you are changing it.

    Difficulties

    • It can be difficult to migrate to a new architecture. You may want to Prototype the Target Solution to get the new architecture in place, and Present the Right Interface to the old system to hide the legacy interfaces while you migrate the underlying components.
    • It is risky to change a running system. Be sure to Regression Test After Every Change.

    Rationale

    You get the best user feedback from a running system. Users are more motivated and involved with a system they use daily.

    Known Uses

    Migrating Legacy Systems [BS95] introduces this pattern under the name “Chicken Little” (to migrate incrementally means to “take Chicken Little steps”). This book discusses in great detail strategies and techniques for incremental migration.

    Related Patterns

    Apply Most Valuable First to select the legacy components to work on first. Appoint a Navigator to maintain architectural integrity.

    Write Tests to Enable Evolution, and Grow Your Test Base Incrementally as you migrate. Be sure to Test the Interface, Not the Implementation so you do not always have to rewrite your tests as you reengineer or replace legacy components. Regression Test After Every Change so you can Always Have a Running Version.

    Consider applying Present the Right Interface for legacy components that you do not intend to reengineer or replace.

    You might consider to Make a Bridge to the New Town if you need to migrate data from legacy components that you are replacing.


    This page titled 7.4: Migrate Systems Incrementally is shared under a CC BY-SA license and was authored, remixed, and/or curated by Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz.

    • Was this article helpful?