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.

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.