A Migration Plan is a complex document since it defines how the enterprise should migrate from the current situation, the current state, to a future state as defined by the IT architecture. It is complex since there are typically many dependencies between system components, and one cannot shut down the system or enterprise during the migration!

There are usually two aspects to a migration plan: operational and technical. Architects must work in conjunction with business analysts to devise a feasible and manageable migration approach. For example, there may be technical advantages to migrating clients over to a new system over an extended period of time, but it may not be achievable due to operational and business rule constraints. Many details have to be sorted out as part of migration planning: when to convert existing data holdings from various sources, when to train staff, which staff will transition to which new roles, staffing levels required, interim operational procedures required during the transition, how and when to transition clients, new installs required and how they will be delivered—the release planning and project planning part of migration.

To start the definition of the migration plan you must first identify the system components that change or are somehow affected while moving to the future state. This step is essentially a Target vs. Existing Gap Analysis where changes needed to system components are identified.

Now the difficult portion begins, the definition of the migration plan based upon, in part, the following factors:

• Cost and benefits of migrating each specific component;
• Required sequencing of implementations (e.g. New database needed prior to a process automation);
• Business priorities, usually driven by a large benefit, but no necessarily;
• Technical priorities (e.g. the failure or imminent failure of hardware or software);
• Resource considerations;
• Complexity defined by the number of dependencies or the technology.

Choosing an evolutionary path for adapting the business to a new architecture having new processes and technologies can be a major challenge, especially for large complex operations. Always look for the changes that can deliver the biggest gains for the dollars spent first. From then on, it becomes a question not only of priorities but of feasibility. The path to the end state must be achievable in a cost effective way and be operationally viable. Make Architectural Decisions that will fit into the bigger picture but carefully assess investments for which benefits might not be gained for quite some time into the future. Make architectural decisions that can adapt and prepare for change based on the need for change in the business domain. Know where you are going, ensure you can always get there, architect for change, and manage premature investments based on the need for future change.

There is value in having a mathematical representation of the business so that cost effectiveness of evolutionary options can be examined. The mathematical model should represent demand (input volumes), throughput, staffing, and processing times. Keep in mind that mathematical models and simulation models are only as good as the data analysis underlying their assumptions (i.e., GIGO: Garbage-In, Garbage-Out). Also mathematical models, and especially simulation models, are expensive to build and should only be considered for larger more complex operations. Some of the techniques for obtaining valid measurements include:

• Gathering and plotting historical input volumetrics to understand trends for future projections.
• Analyzing future input volume through client research and interviews.
• Gathering historical data on the time it takes to perform certain tasks.
• Conducting timing studies to obtain data on the time it takes to perform new tasks or existing tasks that are altered in some way. If task steps are timed individually and only certain steps are being eliminated then the analyst can determine the projected time to perform the altered task. However, if the step time is too minute then the revised task must be represented in some way to obtain an accurate measurement.
• Prototypes can be an effective way of obtaining timing data. However, if the task is completely new, do not underestimate the effect of user practice. A fully trained and experienced user will be able to perform a task significantly faster than someone who has never done the task before.
• Input data quality can also have an effect on processing times and this should be examined also where applicable.
• Analyzing arrival patterns to better understand the peak loads that can affect system sizing and staffing.

Often the mathematical models themselves and the process of devising them can help to identify potential improvements to the business processes. All knowledge gained about the business can assist in making better evolutionary and Architectural Decisions. Intuition can be deceiving. When the numbers are worked out, what you thought could deliver great gains might not.

The architecture models, particularly those at the Business level and Logical level, are also excellent tools for assessing the impact and feasibility of evolutionary options and can highlight the throwaway or transitional requirements—typically these are tasks or steps within a task.

These are only a few of the aspects to consider when defining a migration plan ... whole books have been written on this subject, and should be consulted!