Planning for Migration Success

As you are aware the life of Exchange 5.5 is coming to an end. Consequently over the last 12 months more and more migrations from Exchange 5.5 to Exchange 2003 have been embarked on. In actual fact Microsoft reported a third quarter revenue growth of 12% over the prior year resulting from double-digit growth in the SQL Server™ and Exchange Server product lines

The common thread for all these projects is that no matter what the size of the project the requirements for project management, planning and preparation are the same. It does not matter whether you are a single administrator performing a migration for a small business running a single Exchange server or a team of people coping with a migration from a global multiplatform mail infrastructure, the initial effort is equal. In actual fact if you look at the migration plan as whole you can generally say that the planning and preparation process of the project can be anything up to 60% of the total migration timeline. Generally speaking it is also this part of the project that gets over looked, under estimated and generally cut back. Project managers and systems engineers often set out with the best intentions only to revise the planning and preparation phase in order to meet specific time requirements. In the end this leads to the project over running and encountering difficulty.
So what should you look for if you are looking to complete a successful migration to Exchange 2003. In reality the Planning and Preparation phase can be broken down into two specific tasks. These two tasks can be defined as the Discovery Phase and the Preparation Phase. To understand them fully you need to look at each in turn. The first phase is the Discovery Phase.

1. Discovery Phase
The first part of the Planning and Preparation phase is the Discovery Phase. As the name denotes the Discovery Phase is all about identifying what you currently have. It is key that this phase is completed comprehensively if you wish to put together a realistic Exchange 2003 design, project plan and testing plan. How can you possibly estimate how long things are going to take if you do not understand the factors that will affect the migration?. Typically the first question all project managers will ask the technical team at the beginning of any migration is “How long do you think it will take us to migrate”? The standard answer to this is how long is a piece of string? Although not well received, the answer is realistic.
Before you can even enter into discussions around the timeline you must first complete a rigorous Discovery Phase. To facilitate the gathering of the information the Discovery Phase can be broken into two specific gathering processes. These can be defined as the Business Requirements Gather and Technical Requirements Gather. In general most technical people will be able identify what the Technical Requirements are however they may not be able to readily identify the Business Requirements. It is these soft or Business Requirements that can often make or break your migration.
The Business Requirements will help also you define your migration process i.e. Upgrade, IntraOrg and InterOrg. In order to establish the Business Requirements you must ask two specific questions. :
   a. What are the Service Level Agreements (SLA) for the mail infrastructure?
b. What is the budget available?

Lets look at each one In turn. Firstly “What are the Service Level Agreements for the mail infrastructure?” Although broad this question is vital when defining the migration process and establishing a time line. To get a realistic response to this question you can ask a number of further leading questions that allow you to quantify the answer. These include:
   i. What kind of SLA do you have to maintain?
ii. Is there a mail delivery SLA?
iii. Is there a server downtime SLA?
iv. Generally how important is mail to the business?
v. Can the business function without it for an extended period of time?
vi. Can users be without access to their mail?

Once you the have answers to all these questions you will be able to get a much better picture of the type of mail infrastructure you have to deal with. As previously mentioned this will also allow you to define the type of mail migration that should be performed. For example if the business cannot have any downtime and cannot accept any impact to the users then you would be advised not to use the upgrade process, as this is high risk i.e. if something goes wrong you my need to do a full recovery, and would require a significant downtime and possibly loss of data. If the business is going through a merger you may have to deal with two separate Exchange organisations that have to be merged to separate 2003 target organisation consequently forcing you towards the inter-organisational method.

The second Business Requirements question is “What is the budget available?”. This question is the most defining of all questions. It is this question that will shape the process of any project almost more than any other. If you do not have any budget or time then you cannot do the project. It is vital that you scope the budget effectively up front. Time also needs to be considered as part of the budget. Time in many cases is not considered part of the budget particularly if you are an internal team however it is very important. Information Technology by its very nature is becoming a service based industry and consequently your time is chargeable and although not always directly calculated there is always a cost associated with your time. Again you may need to further quantify the answer to the budget question with a number of leading questions. These can include:

i. What is the budget?
ii. What time do you have allocated?
iii. What people do you have allocated?
iv. When will the budget be available?

Some these questions may be slightly rhetorical and in the fact in some cases if you can justify it you can have as much as you need, however for some companies particularly in small businesses money is often difficult to get hold of. Again this will define the type of migration and also may stop the migration dead in its tracks. It is vitally important to identify upfront if budget will be a problem and then if necessary defend your requirements or revise the businesses expectations. You will also need to be aware of when the budget will be available. If the budget will not be available until next year you will have to revise the business expectations and again explain things like “end of life” and product support.
The second of the gathering processes that needs to be performed during the Discovery Phase is the Technical Requirements Gathering task. The technical requirements are often easier to identify and can normally be quantified more easily through simple mathematical calculations. Again the technical requirements can be broken down into a number of key sub areas. These include:
a. What do you have now?
b. What are you going to?
c. How are you going to get there?

When discussing these questions you are trying to identify what you currently have in your source environment. It is from these particular statistic’s that you are able to estimate the projects duration and confirm the migration process. You may already know the answers to some of these questions from the analysis that you perform during the initial design phases of the target Exchange environment. All these questions if answered will give you a clear picture of what you currently have in place. The first of the questions that need to be addressed to establish your technical requirements is “What do you have now?”. To fully understand this you should look at the environment as a whole. To do this you can ask yourself a number of questions:
i. Number of Mailboxes?
ii. Average size of mailboxes?
iii. Location of mailboxes i.e. Mail Store?
iv. What mailboxes have OST files?
v. Data flow between servers?
vi. How much mailbox calendar information is there?
vii. How are calendars used?
viii. Number of Public folders?
ix. Average size of data?
x. Public folder location? (Where are they homed)
xi. Public folder replication?
xii. Exchange Server specifications?
xiii. Exchange Server resource utilization?
xiv. Routing diagram?
xv. Network diagram?
xvi. Types of users? (How will laptop users’ profiles be updated?)

Although the questions above give you details around specific environment information there is a number of other things that need to be identified in order to ensure a successful migration. On top of identifying the specifics around the environment you must also consider the following:
xvii. Users with multiple mailboxes
xviii. Service or Admin Mailboxes
xix. Orphaned mailboxes
xx. Public folder permissions set via Distribution Lists. As you know Distribution Lists are translated into Active Directory as distribution groups or security groups. To permission a resource in Active Directory you must use a security group consequently our Distribution Lists from Exchange 5.5 must be converted to a mail enabled security group to allow permissioning of the public folders to take place. By default when you migrate distribution lists to Active Directory they will be translated into distribution groups. Exchange 2003 is able to translate these to security groups on the fly however the target 2003 domain must be in native mode. .
xxi. Mailboxes exceeding quota’s
xxii. Third party software or applications that integrate with Exchange

It is natural for you to consider ‘what is the biggest ‘gotcha’ during migration that can affect the business directly? Minimal discovery, planning and testing are obvious the ones; however there are three specific issues that are of immediate concern.
The first issue that will cause any migration from Exchange 5.5 to fail is the users with multiple mailboxes issue. Even if this process fulfils a business requirement there are new ways of doing this in Exchange 2003 by assigning the appropriate rights to the user, however this it does not take away the fact that each mailbox must have it’s own user account. Consequently the Exchange migration team must liaise with the domain migration team to facilitate the creation of the extra user
The reason the user with multiple mailboxes is such a big issue is due to the major shift in architecture between Exchange 5.5 and Exchange 2003. The change is centred on how the user account is associated with the mailbox. In Exchange 5.5 one user could actually be the owner of a number of mailboxes. For example the Reception staff are often owners of their own mailboxes and also other mailboxes such as the meeting room mailboxes. In Exchange 2003 this is not possible. In Exchange 2003 each mailbox is now an attribute of the user account created in Active directory and therefore can only own one mailbox. You can build the same relationship in Active Directory accounts.
Second issue of initial concern is the use of 3rd party applications. Even with robust discovery, 3rd party applications can give a broadside to any Exchange migration project in respect to extending the project timeline. These applications come in many forms such as the utilisation of connectors, SMTP Relay, Mailboxes, Public Folders, use of the 5.5 Directory and hard coded Exchange 5.5 server names. There are departmental and business critical applications ranging from public relations inbox to the likes voice mail systems and ERP/CRM systems that can also cause issues.
The third gotcha that needs to be identified and planned for adequately is what to do with service or administrative mailboxes. Now although the in depth discussion of how these should be handled is out of the scope of this article it is important to identify them and plan the migration strategy around them.
The next question you have to address in order to define your technical requirements is “What are you going to?”. This investigation can be done in parallel or sequentially with the investigation and reporting on the source environment. In most cases the target environment will be a Greenfield environment however there are some cases such as during a merger or acquisition when this is not the case. When performing discoveries against the target environment you are primarily interested in identifying the target infrastructure to allow you to plan for the migration. Again a large amount of this information should have been gathered in the initial design of the Exchange 2003 environment however when identifying “What you are going to” you should still consider the following:
i. What are the mailbox quotas?
ii. Where will the storage groups be located?
iii. How will the mailboxes be distributed across the storage groups?
iv. Routing groups?
v. Admin groups? (Who will administer what and where will they administer from?)
vi. Recipient Policies and filters. (How do I give a specific group of users a specific SMTP domain for their email)

The key point here is that you must be aware of any specific policies in the new Exchange 2003 environment. This can include not only Exchange policies such as mailbox quotas however planning and discovery should also take account of wider polices such as password polices and any other Group Policy that may affect the user when accessing their mail. For example if the user will have a smaller Mailbox Quota in the target than in the source then you may need to consider processes for reducing the mailbox size through alternatives such as an Archiving system.
The third question that you need to address to help identify the technical requirements of our Discovery Phase is “How are you going to get there?”.
Again to help you answer the broad question you can break this into a number of smaller questions.
i. What type of migration will you perform?
ii. What are your timings?
iii. What will the process be?

What process or procedure you choose to migrate your mail data and associated resources will be based on the data you have already gathered. There are numerous articles available to assist you in deciding which process to choose including literature from Microsoft and from third parties such as Quest Software. The main thing to consider here is timing. How long you do have and how much resource you can use. When considered in parallel with the business requirements the process should be relatively clear.
The final task of the Discovery Phase is to establish the actual migration plan. This will detail the rest of the tasks and define the timeline that will drive the migration process. The actual details of this plan are unique to each project and are therefore outside the scope of this document however it is imperative that you have a well documented plan that you can follow. If you are currently also performing a domain migration this plan should be developed in conjunction with the domain migration plan. As Exchange 2003 uses Active Directory for its underlying directory structure the Exchange project is dependant on the domain migration a point that is often lost on many Exchange administrators migrating from NT and Exchange 5.5.

b. Preparation Phase
The second part of the Planning and Preparation phase of the migration is the Preparation Phase. This phase is dedicated to the cleanup operations that are required to prepare both the source and the target environments for the migration. As in the Discovery Phase a lot of these tasks can be done in parallel however you will still need to think about the sequence carefully. It is vital these are done thoroughly and effectively otherwise you can set your project back days if not weeks.
When preparing for your migration the most important preparation tasks are associated with the source environment. During this time you have a great opportunity to cleanup Exchange. If you perform the Discovery Phase correctly the information you require for the cleanup will be at your fingertips. The migration to Exchange 2003 will also give you the opportunity to redesign your infrastructure and take advantage of the new features and processes offered to us by Exchange 2003.

a. Preparing the Source Environment

If you think about your source mail infrastructure and particularly Exchange 5.5 it is probably safe to say your environment was designed three to five years ago and as a result was designed around the facilities available to you in Exchange 5.5. Often the new methodologies of consolidation and recovery that Microsoft now promotes with the design of Exchange 2003 do not fit your current infrastructure and so a full redesign is required. Consequently you need to look closely at the design of your Exchange environment and make sure you are taking full advantage of the features available in Exchange 2003.
When you come to cleanup our source environment you need to focus on cleansing the data. This includes:
i. Assigning a one to one relationship between mailbox and primary NT account
ii. Removing expired distribution lists
iii. Cleaning up public folder structures and archiving infrequently used data
iv. Have users reduce mailbox size
v. Ensuring the validity of the actual data within the directory itself i.e. Address, Phone numbers.

In environments that are synchronising multiple Exchange organisations to a single target Exchange 2003 organisation you will also need to be aware of distribution lists with cross organisational membership and other replication issues caused by latency in replication. Consequently you will also need to:
vi. Ensure inter-site replication is working correctly and there are no SMTP address conflicts.
vii. Ensure Public folder replication is occurring correctly
viii. Confirm there are no internal communication issues.

Prior to the migration you should also upgrade to the latest Exchange service packs on the source and target and ensure you have a complete backup that is able to be restored quickly and effectively.
Another area you need to define clearly before starting the migration of a single mailbox is around process or procedure. You will need to define and enforce how the business will function during the migration. There are three key processes that need to be defined:
ix. New starters policy
x. User operational movement policy
xi. Leavers policy

Essentially you need to define how new mailboxes are going to be created and how old users mailboxes will be removed once the migration process is under way. You need to be very careful not to undo the cleanup work you have already done by implementing old procedures. It is not unheard of for companies to spend a week or longer cleaning up the Exchange 5.5 directory of users with multiple mailboxes only to have the helpdesk create five more on the following Monday.
It is imperative that you define your procedures before the migration begins and then enforce them heavily. You must also liaise closely with the directory management team to ensure that they are creating users that the Exchange migration directory synchronisation can match onto. This is even more critical if there is a domain migration under way as well.

b. Cleaning up the Target Environment

The second part of the preparation phase is the cleaning up of the target environment. Although most of the preparation tasks are considered during the Exchange 2003 design phase and implemented during the installation of Exchange 2003 you should still consider:
i. Active Directory design needs to be completed and implemented
ii. Organisation Unit structure should be in place and documented.
iii. Security model designed and implemented
iv. Deploy the core infrastructure including domain controllers, paying special attention to GC placement and availability
v. Deploy Exchange and implement the designed configuration .
vi. Backup and recovery strategies in place and tested for Active Directory and Exchange

Although very basic points Exchange Administrators often forget about Active Directory or overlook the importance that it now plays as the underlying directory structure of Exchange. The replication of information into Active directory needs to be managed very carefully and in a controlled manor. If you do not prepare for this process effectively you will inevitably hit difficulties.
Along with the implementation of Active Directory and Exchange you need to consider some of the peripheral processes as well. You need to ensure that:
vii. Items such as the proxy server are updated to allow authentication from both domains.
viii. The users must be able to authenticate and resolve names in both domains via DHCP, WINS and DNS.

You will need to ensure that you have a well managed and controlled Active Directory. If you have any issues with your directory these will only be exacerbated during the migration. In my experience the majority of issues encountered by a migration team are caused by external issues, whether it is a failure in network communication, a DNS issue or directory replication problem and unfortunately in most cases it will be blamed on the migration process.
The key thing to keep in mind when you are preparing for any Exchange migration is that the more you know and can plan for upfront the less likely you are to run into issues.
This document is by no means an exhaustive checklist for an Exchange migration. The aim is to make you think about the complexity involved even in the smallest migration process and then allocate the appropriate time. Keep in mind you are not alone in this process. There are numerous resources available to assist you through your migration including Microsoft’s TechNet, various blogs and third parties who specialise in this. Just remember to plan, prepare and test before embarking on the process.

Comments

• Anonymous
  January 01, 2003
  Matthew has written a very comprehensive article about all the things that you need to think about and...
• Anonymous
  September 02, 2005
  I'm throughly impressed with this article. I've been considering a migration of my company's Exchange facilities for some time now and will definitely take some of Matthew's points on board.
• Anonymous
  October 05, 2005
  Well, somehow unstructured but extremely useful information is lying here.
  
  Thanks !