Skip to main content
Engineering LibreTexts

7.1: Migration Strategies

  • Page ID
  • Your reengineering project is well underway. You have developed a good understanding of the legacy system and you have started to Write Tests to Enable Evolution. You have gone through a process of Setting Direction and have decided to tackle the Most Valuable First.

    How can you be sure that the new system will be accepted by users? How do you migrate to the new system while the old system is being used? How can you test and evaluate the new system before it is finished?


    • Big-bang migration carries a high risk of failure.

    • Introducing too many changes at once may alienate users.

    • Constant feedback helps you stay on track, though it may be difficult and costly to achieve.

    • Users have to get their work done; they don’t want to be distracted by incomplete solution.

    • Legacy data must survive while the system is being used.


    It is not enough to reengineer a legacy system and then deploy it. In fact, if you try this, you will surely fail (for the same reasons that big Waterfall projects in new territories often fail). You must be prepared to introduce the new solution gradually, to gain the confidence and collaboration of the users, and you must adopt a strategy for migrating gradually and painlessly from the existing system, while it is still being deployed, to the new system.

    How, why and whither to migrate legacy systems.
    Figure \(\PageIndex{1}\): How, why and whither to migrate legacy systems.

    The central message of this cluster is to Migrate Systems Incrementally. This is, however, easier said than done. In Figure \(\PageIndex{1}\) we can see that in order to Migrate Systems Incrementally, we should consider a large number of other patterns. Since there exists a vast literature on system migration, we do not attempt to cover the topic in great detail. We have selected, however, the patterns that we consider to be most important for reengineering object-oriented legacy systems, and summarized the main points. Where appropriate, we point the reader to further sources of information.

    Although the central pattern of this cluster is Migrate Systems Incrementally, the key motivation is provided by Involve the Users and Build Confidence. These first three patterns are fundamental patterns for minimizing risk and increasing the chances of success:

    • Involve the Users increases the chance that users will accept the new system by involving them closely in the entire reengineering process, getting them to use intermediate results, and providing them with strong support. It is easier to achieve if you Migrate Systems Incrementally and Build Confidence step by step.

    • Build Confidence helps you overcome skepticism and doubt by regularly delivering results that are of value to the users.

    • Migrate Systems Incrementally recommends that the old system be gradually and incrementally replaced by the new system. New results can then be integrated as you proceed, thus helping you to Build Confidence and Involve the Users.

    It is very hard to Migrate Systems Incrementally unless you also adhere to the following practices:

    • Prototype the Target Solution to test the new architecture and new technical risks. It is too easy to be tempted to think you don’t need a prototype since you already have a running system, but this is almost always a mistake.

    • Always Have a Running Version helps to keep changes in sync by ensuring that they are integrated frequently.

    • Regression Test After Every Change helps to you Always Have a Running Version by making sure that everything that used to run still runs. It presupposes that you Write Tests to Enable Evolution.

    Depending on the circumstances, there are various practices that may help you to Migrate Systems Incrementally:

    • Make a Bridge to the New Town introduces the metaphor of a (data) “bridge” to allow you to gradually migrate data from a legacy component to its replacement, while the two run in tandem. When all the data have been transferred, the legacy component can be retired.

    • Present the Right Interface helps you to develop the target system in increments by wrapping the old functionality to export the abstractions you really want.

    • Distinguish Public from Published Interface distinguishes between stable (public) and unstable (published) interfaces to facilitate parallel development within a reengineering team.

    • Deprecate Obsolete Interfaces lets you gracefully retire obsolete interfaces without immediately invalidating clients.

    Finally, the following two practices may help you avoid making radical, but unnecessary changes:

    • Conserve Familiarity warns you against introducing radical interface changes that may alienate users.
    • Use Profiler Before Optimizing reminds you to delay considering performance issues until you can demonstrate that you have a problem and can pinpoint the source of the problem.
    • Was this article helpful?