Migrate Incrementally (aka Chicken Little).
Context A legacy system is to undergo reengineering to realise benefits for the organisation. You wish to minimise the risk of: system outages during cut-over; bugs in the target implementation; project cancellation; changing requirements; and systems becoming unsupported. In addition, you need to make best use of limited resources.

Although you expect reengineering to benefit the organisation, such an activity will, itself, carry risks which are difficult to predict, quantify and obviate. The scope of the project appears to be too large for the amount of resources available to support the necessary effort. If the project's timescales are stretched so as not to overload resources, requirement are more likely to change. If extra resources are acquired (for instance staff and equipment), project costs will rise and there will be an extra training burden. Changing requirements threaten to undermine reengineering efforts, yet you cannot ignore changing requirements since the credibility of the project, and hence its future viability, depend on satisfying users and business objectives.

Problem What is the best strategy with which to execute a large, complex reengineering project?
Solution Plan for a incremental, phased migration from the legacy to the target architecture. Decompose the legacy into sensible components. The reengineering of each decomposition becomes a phase in the project. Balance the effort involved in each phase with the available resources. Ensure that, throughout the project, there is an operational hybrid legacy/target system. Prioritise the order in which phases should take place based on the most pressing objectives being addressed first.
Consequences Decisions on how best to decompose the legacy could be based on any existing hierarchy of interfaces, logical code and data or the likelihood of certain hardware or software components becoming unsupported. Alternatively, tackle mission-critical phases first to raise the profile of the project. If databases are migrated early, redundancy can be identified which can help rationalise subsequent phases. Stand alone applications are more straightforward to migrate than those which are tightly coupled with other systems. This approach may lead to a quick success which helps the project's credibility, but could overlook more critical migration candidates. 

When some application has its interface, logic and data too tightly coupled for them to be individually excised, you may wish to wrap that part of the legacy. However, this will perpetuate the use of potentially unsuitable legacy components.

Since the system is operational after each phase, the benefits of the project can be realised quicker than if the whole legacy were migrated and deployed at once. Also, bugs are easier to find and correct in a small component than in a large system. This reduces the project's risk and inconvenience to users.

If, while balancing the resources and effort required for a phase, there is a significant disparity, consider subdividing or combining phases. Additionally, to make best use of different team skills, preparation for a later migration may be able to take place in parallel with the deployment of an earlier phase.

Requirements creep is always a risk while reengineering. However, with each phase, new requirements can be accommodated throughout the project. If you suspect change is likely, you may wish to reengineer early those phases which are less likely to be affected. In addition, if each phase is delivered quickly, users may have less time to think up changes.

Realizing benefits early, reducing the impact of bugs and minimising the disruption of new and changing requirements gives the project credibility and will help secure its future funding. However, if circumstances change and the project is not to be continued, the end of each phase leaves the system operational and having prioritized the phases, the most important issues will already have been addressed.

It is likely that there will be a number of dependencies between system components. Using gateways, you will be able to let disparate parts of the emerging architecture communicate. If you are ultimately aiming for a distributed system, early adoption of a middleware product allows you to provide consistent interfaces between components, so insulating the system from changes that occur behind the interfaces.

Cutting over from the legacy to the target is risky. You may wish to let the legacy and target components coexist until it is convenient to change to the target. However, maintaining a legacy and target implementation of the same function is costly. Therefore, plan to retire legacy components as early as possible. For databases, this may be achieved by restricting updates to the new database and only conducting queries on the legacy - gradually the legacy will die. For a user interface, invest in training as near to deployment of the new interface as possible and make users aware that the old interface will cease to be operational beyond a certain date. In this way, users are less likely to forget what they have learned and revert back to the legacy interface. If they do revert back or are slow to adopt, they know they have a limited to time to conform and will feel encouraged to do so.

Related Patterns When wrapping seem inevitable, consider Wrapped Service. Since the user community will experience change, you may wish to adopt Support the Change.
Known Uses Plaisant et al. [15], Duncan & Lele [11], Hughes et al. [12], Olsem [18] and Brodie & Stonebraker [19] have all adopted incremental migration.