PPCM - The Transition Phases

  • [アーティクル]

Over the past seven+ years I have been directly involved with deployments and transitions for a variety of Microsoft technologies (Exchange, Active Directory, Windows 2000/2003, MIIS, and more). During these years I have met with literally hundreds of customers to review their transition plans and from these reviews I saw four common transition phases emerge. In these transitions (transition meaning the process of changing from some start state to a desired end state, usually through introduction of some new technology to enhance or replace existing functionality) the phases followed common deployment sense, so they were present regardless of if they were specifically called out in any project. I wanted to blog at a high-level about these phases since they are so common and are universal to different technology transitions. Also this sets the stage for more detailed blogs later as we get into our tools since the different tools and guidance that we have released (the messaging tools) and will release (like the Application Analyzer) all refer back to these phases.

 

PPCM – Plan, Prepare, Coexist and Migrate: As I stated, these are really just common sense, but still it is important to understand and map out these phases to understand the overall flow of a transition to some desired end-state.

 

Plan Phase: This is the initial phase where the goal is to create the plan for the following phases. This state usually includes some level of discovery of the current system through analysis, and of the target technology through research (such as training or documentation) and/or a proof-of-concept deployment. The idea is to define (a) what the current state really is, (b) what is the desired end-state will be, (c) and what is the path that will get you there.

 

Prepare Phase: This phase is all about getting the topology ready for a transition by laying a foundation for the target state and preparing the source system. For example for a transition to Exchange the foundation would include the deployment of Active Directory, deploying initial mail servers, setting up message flow, etc. This phase would also include a pilot environment and training of administrators who will support the target system. Also, any cleanup on the source (such as removing unused databases, old mailboxes, etc.) would be done here. Again the idea is to get everything ready for running live.

 

Coexistence Phase: The Coexistence phase is when you are running live with the target system, but need to retain functionality from the current system. Often this is because the transition could take place over a long period of time (very common for large mail transitions) or simply may be because different set of functionality is provided by the new system. For example, you may have been using Domino for customer tracking and employee lists, but plan to centralize HR functionality to an off-the-shelf HR management system that tracks employees plus provides additional HR features. The end-state then may be a combination of the Domino Server (for the legacy customer tracking solution) and the new HR system. Because of the different needs for coexistence this phase may actually be the end-state. I know of many companies that run and co-exist with legacy systems for years simply because there is not the business case to move some functionality from the legacy system, but more than enough business case to move forward with new technology in different areas. Also on the other extreme co-existence can be short (or NONE) if a simple swap-out approach is taken. Either way, the goal in this phase is to begin to gain the value (run live) from the target system, while retaining functionality needed from the current system regardless of if a migration is later planned.

 

Migration Phase: This is the actual phase of moving off one system to the target system. The migration phase is often done in conjunction with the coexistence phase. For example you may be migrating mailboxes from Domino to Exchange, while still providing co-existence for mailboxes that have not yet migrated. The migration phase will consist of two parts, a data migration (work to provide access to legacy data from the target system), and functionality migration (work to provide similar required functionality in the target system). The approach taken for these varies greatly, from a rip-and-replace strategy where nothing is migrated, just the new system is now running, to a very detailed migration approach where all data is preserved and all functionality is replaced with a similar interface as before. Bear in mind that in the cases when co-existence is the desired end-state, then the migration phase may not come into play, depending on what the new system provides. In the end, this phase is about how data and functionality is to be moved to the target system to enable the desired functionality in the target.

 

I realize that this is all high-level and does not get into specific features, but given how often these come up in transition discussions I wanted to set the stage by a) calling out these common-sense phases so that they are at least defined and understood, and b) lay the foundation for more detailed blogs later on the tools and how they work within these phases.

 

Erik Ashby

Comments

  • Anonymous
    January 01, 2003
    Whew, what a busy few weeks. Especially with the releases we announced yesterday about new tools and...