Mastering the art of Exchange 2010 migration documentation

Documenting your Exchange Server 2010 migration is an often-overlooked part of the upgrade process. Learn why it’s important and what to include before putting pen to paper.

There is a lot to consider when planning an upgrade to Exchange Server 2010 and each project will be intrinsically...

different from one organization to another. However, one central commonality is the need to document the entire project if you expect others -- administrators and users -- to understand the objectives and methods used.

Although it may be very tempting to roll up your sleeves and jump right into a migration, don’t. Before you even put the Exchange 2010 installation CD into the drive, it’s important to establish your existing documentation baseline and then plan how you’re going to get from point A to point B.

The initial move and easiest way to create a document, is to take a step back, review existing documentation and update it as needed. Most often, however, a simple update won’t be enough and you’ll need to create a new migration document from scratch.

The document must take into consideration storage, processor, memory and network requirements not only for the migration project itself, but also for Exchange Server’s lifecycle. You’ll also need to think about the evolution of supporting software within your Exchange environment, whether Exchange 2010 will need to remain compatible with other server versions during the upgrade and what line-of-business applications will operate in your environment. This tutorial will give you the framework for logically designing, planning and drafting a solid migration document.

Filling in the documentation blanks
You can use existing Exchange documentation as a reference on which to base your new migration document. But don’t expect to completely count on old documentation. There are many reasons why baseline system documentation can become out-of-date. And although documentation should be an evolving creature -- changing with upgrades, service pack installs, patches and so on -- not all administrators are diligent in inputting changes as they occur.   

Why should you be wary when reviewing existing documentation? Consider the following scenarios:

  • You are consulting or have started a new role where you have to upgrade from Exchange 2003 to Exchange 2010. The former IT manager or administrator didn’t thoroughly document the previous move to Exchange 2003.
  •  You have been in charge of an Exchange Server infrastructure that’s moving to Exchange 2010. This old configuration has been in place for a number of years, and there have been several undocumented changes.
  • Patches, service pack installs and hot fixes don’t always make it into system documentation because they may have been installed in a rush.

Layout and audience selection
After you review existing documentation, the next move is to meet with key stakeholders -- the chief technology officer, security managers and other Exchange admins, for example -- who will be involved in the migration. Together, you should identify the elements that you must include and the overall structure and tone of the document.

For example, some companies prefer migration documentation to take the form of a purely technical manual, primarily targeting administrators with a strong knowledge of IT resources. This type of document might get right into the technical information and include the following pieces:

  • Hardware design information
  • Exchange sizing information (CPUs, storage elements, memory requirements)
  • Networking configuration
  • Exchange settings (routing, server role settings)
  • Specific third-party tools and interfaces
  • Coexistence information
  • Mailbox configurations
  • Eliminated features
  • Implementation steps

Other companies may prefer their migration documentation to be all-encompassing and contain project lifecycle planning and reporting, as well as technical elements. For example, a more holistic migration document might contain:

  • Project overview
    • Mission statement detailing the purpose of the upgrade
    • Project goals
    • Budget planning and allocation
    • Project strategies (communications plan, risk management plan)
  • Hardware considerations
  • Storage
  • Public folder migration
  • CPU, memory and networking
  • Software considerations
    • Software compatibility
    • Internal, line-of-business (LOB) software
  • Coexistence scenarios
  • Mailbox configurations
  • Eliminated features
  • Implementation steps

Now, let’s take a closer look at what each portion of a nontechnical Exchange Server 2010 migration document could cover.

Project overview

Mission statement. The mission statement of a migration document should state the high-level purpose of the entire project. For example, this could consist of a simple statement noting that you’re currently running Exchange Server 2003 and that you’re moving to Exchange 2010 to take advantage of new features and long-term support benefits. In your mission statement, you may also want to include details on efficiencies or savings gained from migrating to Exchange 2010. Keep the mission statement brief and plan to elaborate on points made here in the project goals section.

Project goals. In this section, go into more detail on your mission statement by addressing specifics of your migration project. The idea here is to create a checklist of sorts that you can refer to throughout the project. A completed checklist at the end of the project will make it easy for stakeholders to get an overview of the steps involved and the overall success of the project. For example, this section could include the following details about how many servers and which servers will be involved in the migration:

  • Move 4,000 users based on four sites from seven existing Exchange 2003 clustered mailbox servers to four Exchange 2010 servers with database availability groups implemented for high availability.
  • Decommission three existing Exchange 2003 front-end servers and replace them with two Exchange 2010 client access servers.
  • Migrate existing CRM and service desk applications from MAPI-based integration to Exchange Web Services.

Budget planning and allocation. Although this section isn’t necessary, some companies find it useful to outline the anticipated costs of the migration project lifecycle, including overall budget allocated, itemized costs (e.g., $40,000 for servers; $60,000 for software), any available contingency budget in case you overspend in a particular area as well as information on how your department will report budget changes to stakeholders.

Project strategies. In both large and small migration projects, it’s worthwhile to define a number of management strategies for more specific stages of the migration project. There are two main strategies that should appear in the migration document:

1. Communications plan

2. Risk management plan

Since the purpose of your Exchange Server migration is not purely a technical refresh -- it will also benefit your business and customers -- your migration documentation should identify any points in which customers may notice differences with communication or disruptions in email services. Your communications plan should specify this.

Within your documentation, for example, you may want to provide a timeline that identifies when to expect planned outages to services, how long the outages will last and any ways to lessen the impact of these outages on users. It might also be valuable to document less-critical occurrences, such as the fact that users won’t be able to send or receive email while their mailboxes are moving to the new server.

A well-managed migration won’t seem like a disruption to users or customers. Including details like this can help you make the migration experience more pleasant for the user base.

All migration projects should also have in place a list of risks and a management plan. Before beginning the migration project, you would have identified all relevant risks -- internal technical risks and external influences. The section containing your risk management plan should include how risks are identified and officially placed within the risks register. This will be useful in case auditors want to see how the project was managed.

You may want to use other strategies, including reporting progress and financial management, for example, but standards within your individual organization will dictate those components.

Hardware considerations
Although they may appear a few pages into your migration documentation, hardware details are the most important aspect to include. And, in many cases, this will be the most detailed section of your document as it contains the underlying technical design of your Exchange infrastructure.

Storage. The first entry under hardware considerations, and the key to an effective Exchange installation overall, is good storage design. Your document should capture the essence of your storage hierarchy. Key elements for this section should include:

  • Results of a disk IOPS analysis according to mailbox and transport profiles within the Exchange organization. This information is easy to capture if you use the Exchange 2010 storage calculator, which automatically calculates storage requirements according to your Exchange organization size and requirements. You can adjust the tool according to your needs.
  • Analysis of RAID-level designs explaining why you’ve chosen that particular RAID design for your storage volumes. Link this info to the IOPS analysis as well as a database and transaction log table.
  • Logical table of your database and transaction log layout (Table 1). When combined with the IOPS analysis and RAID-level designs, the table should give users a good overview of what you’re trying to achieve from a storage standpoint.
Physical hardware array Drive ID Size Tolerance Exchange allocation
          A Logical drive 1 4,000 MB Raid 1+0 Cluster quorum
          A Logical drive 2 4,000 MB Raid 1+0 Msdtc* resource
          A Logical drive 3 26,731 MB Raid 1+0 Exchange cluster drive
          B Logical drive 4 70,005 MB Raid 1+0 General store logs
          B Logical drive 5 70,005 MB Raid 1+0 Vip store logs
          C Logical drive 6 420,041 MB Raid ADG Vip store db
          D Logical drive 7 420,041 MB Raid ADG General store db

                                                                        *MS distributed transaction coordinator

Table 1. Here’s an example of a database and transaction log layout.

Additionally, it’s a good idea to document your database layout from an Exchange perspective. For example, explain which databases will go to production, which will go to test and development and where all of these databases will reside in relation to the physical and logical disk layout. You should also include information on which databases are database availability group (DAG)-enabled, if applicable.

Public folder migration. Moving public folder content over to Exchange 2010 can be a huge challenge, especially if users rely heavily on them. It’s important not only to document the existing public folder infrastructure and permissions, but also to have a good plan in place for moving them over to the new environment.

CPU, memory and networking. This section is meant to give users or auditors an understanding of why you chose specific hardware for Exchange 2010 server roles. Similar to the storage calculator you used to run an IOPS analysis, you can use Microsoft’s Exchange 2010 role calculator to obtain the specifications for various server roles.

You should also take into consideration any networking configuration changes that will occur during the migration. Will firewall configurations change and, if so, how? Will you need additional interfaces? What will the new IP configuration look like? Proper migration documentation should answer these questions.

Software considerations. It’s common that you’ll need to install supporting software to add functionality or provide increased resilience to the core Exchange Server deployment. You’ll also need to support custom software.

Software compatibility. Check with software vendors to ensure that there are tested upgrades available that are compatible with Exchange 2010. Ancillary software often can be placed within one of the following categories:

  • Archival software
  • Antivirus protection
  • Backup tools
  • API-dependent software such as EWSAPI

Documenting the supporting software’s baseline position in terms of compatibility with Exchange 2010 (as shown in Table 2) will help you avoid migration project delays.

Software Description Current version Exchange 2010-supported version Status
TotalSpace Backup for Exchange Primary backup Upgrade available
AnswerIT Compliance Manager Vaulting solution 8.2.11 9.0.0 Not released

Table 2. Here’s an example of how you’d document your inventory of supporting software.

Internal, LOB software. Most organizations run several custom internal applications. Carefully document such applications to be certain that migrating to Exchange 2010 won’t crash your CRM or present other problems.

Document all dependencies that systems external to Exchange have within the environment: which systems relay off SMTP virtual servers (including Unix boxes), which systems use mailboxes within the Exchange environment and how those systems connect to determine if you need to change any settings. Additionally, document if you have any third-party systems that integrate directly with Exchange, such as legal casework software or workflow applications, that you may need to reconfigure.

Coexistence scenarios
If your migration project involves a move from either Exchange Server 2003 or Exchange 2007 to Exchange 2010, you’ll most likely have to manage the coexistence of two server versions during the upgrade. In a coexistence scenario, multiple versions of Exchange communicate with each other and share resources as well as recipient and configuration information.

Also, in a coexistence scenario, certain departments will use Exchange 2003 functionality while others will use Exchange 2010 features. Table 3 lists some coexistence issues you should factor into your documentation.

Technology Explanation Server version Additional information
Active Directory and domains When performing the upgrade, grant specific Exchange permissions in each domain within the forest in which you ran Exchange 2003’s “domainprep” command. To do so, run and document the domains needed to run this and check them off as each operation completes. Exchange 2003 in coexistence with Exchange 2010 Prepare Active Directory and Domains
Native mode You can only deploy Exchange 2010 within an Exchange 2003 organization that’s running in native mode Exchange 2003 in coexistence with Exchange 2010

Understanding Upgrade to Exchange 2010


Server management Use native Exchange server management tools to administer the Exchange version and prevent configuration value corruption. Exchange 2003 and Exchange 2007 in coexistence with Exchange 2010

Exchange Management Console Interoperability


Native Exchange 2010 role coexistence Certain Exchange 2010 roles in coexistence with a previous version are only used when a user mailbox is migrated to the platform. Exchange 2003 and Exchange 2007 in coexistence with Exchange 2010  
Mail-routing topologies Installing Exchange 2010 in an existing Exchange 2003 organization changes mail-routing methods. Each version of Exchange will maintain its own routing topology, but you need to understand how mail will be routed between two coexisting server versions. Document existing routing groups with SMTP connectors or Send/ Receive connectors. Exchange 2003 and Exchange 2007 in coexistence with Exchange 2010 Upgrade from Exchange 2003 Transport

Table 3.Here’s an example of some Exchange 2003 and Exchange 2010 coexistence considerations.

Mailbox configurations
Many organizations use transport limits and mailbox limits. If your organization does, you should list them in existing documentation. With Exchange 2010, you may want to consider increasing these limits based on recent storage calculations. Carefully document any changes to limits as well as changes to log file paths (IIS logs, tracking logs, transport logs); the virtual directory; authentication settings; certificate settings.

Eliminated features
With the introduction of Exchange Server 2010, Microsoft eliminated a few features. Exchange Web Services has replaced certain Exchange 2003 API features, including MAPI32, Exchange WebDAV extensions and store events. Be sure to document that these features will no longer exist in the environment after the migration is complete.

Implementation steps
The final section of your migration documentation should explain the actual method and steps used to move from Exchange 2003 or Exchange 2007 to Exchange 2010. In this section, include time scales, tasks, resources and dependencies. The main point is that you should include a very detailed description of how you will get from point A to point B during the project. 

You should now have you a good a grip on creating documentation for your own Exchange migration project. Keep in mind that you may have to adjust certain parts of your document to suit your organization, the migration project and your particular goals.

Andy Grogan,
an Exchange MVP based in the U.K., has worked in the IT industry for the last 14 years -- primarily with Microsoft, HP and IBM technologies. His main passion is Exchange Server, but he also specializes in Active Directory, SQL Server and storage solutions. Andy is currently working for a large council in West London as the Networks and Operations Manager supporting 6,000 customers on more than 240 sites. Visit Andy’s website at

This was last published in August 2011

Dig Deeper on Exchange Server Deployment and Migration Advice



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.