Go to Top

Microsoft Exchange 2010 migration

Microsoft Exchange 2010 migration

Due to economic uncertainty and limited budget resources, many organizations may delay performing needed hardware or software upgrades. A case in point—a recent survey at an email messaging user group revealed that many IT administrators are running Exchange 2003 and are only going to upgrade when Microsoft pulls its support of the product in 20141. This means the IT department is left with only a short time frame to negotiate license seat pricing, begin testing and migration planning, and get upgrade costs built into the next budget cycle.

Budgets are strained, so accounting for all involved costs and developing a proper planning exercise is what your IT leadership will be expecting before agreeing to such a project. It takes time and resources to develop an all-embracing project proposal, so do not wait until the last minute to plan for your email system upgrade.

Exchange 2010 Migration

Management commonly views computer system upgrades as straightforward and relatively easy; the IT team comes in on a Saturday, runs a few tests on Sunday and everything works and is ready for Monday morning. However, moving to Exchange 2010 is not an upgrade path—it is a migration path. This means your team will need to build a new Exchange server that will coexist for a time with the existing system. Exchange 2010 incorporates many changes and management features. As part of your migration preparation, provision a virtual Exchange system to become familiar with Exchange 2010. (Install a beta or virtual test-drive with a trial version of the system by downloading it from here.)

Most large-scale IT projects exceed their budget by 20 percent; do not let that happen to your project. A successful migration requires a methodical approach. Here is a high-level overview of the areas you will need to cover. Be careful; do not treat this list as your migration plan checklist or important details will be lost during your migration. The list below provides the items of a typical migration project. Here is what you will need to do before the migration takes place:

  • Stakeholder meetings
  • Current server environment review
  • Mobile server support resource review
  • IT support resource review
  • Desktop support resource review
  • Documentation (project and server)
  • Documentation (user documentation)
  • Third-party software integration review
  • Mailbox migration process
  • Hardware requirements
  • Storage requirements
  • Network requirements
  • IT security and compliance requirements
  • Risk management and disaster planning
  • Pilot rollout for small groups
  • Rollout for entire organization
  • Post-migration tasks, cleanup, secure disposal of previous equipment and data

Expect issues with server functionality after the migration is completed. This is where strong troubleshooting skills are required to find the problem. Based on real-world experiences, your network infrastructure may need to be altered in order to accommodate Exchange 2010. This should be the starting point when investigating functionality issues.After the new server is up and all of the service packs have been installed, it may seem that the next step is to start migrating user mailboxes. However, the first step with the new system is to confirm its functionality. For example, is the new server communicating, without network delays, with the domain infrastructure? Are Active Directory domain policies apparent via the management console? What about outside network communication to the server—do not assume that using the older server’s DNS protocols will work; disjoint namespaces may need to be thoroughly vetted before the system will communicate properly2. Finally, ensure that your server certificates are up-to-date and install them.Exchange 2010 has added features to assist in post-deployment verifications. On the Exchange Management Console, you can check the “Organizational Health” and get a refresh of the server summary and recipient summary. Produce an itemized listing of all of the possible issues by starting the Best Practices Analyzer from the Management Console’s Toolbox menu. This will provide you with a very detailed report—everything from server configurations to connectivity verification.

When your organization’s budget opens up and you get the green light to proceed with your project, you will be able to deliver it on time, within budget and without losing data, all the while maintaining your company’s IT security policies.

Migration Planning and Documentation

Systematic migration for an organization’s email system is better than a rip-and-replace approach. Projects such as these are difficult because the current email server, mail-routing topologies and network infrastructure have grown with the needs of the organization over the years. Current configuration and settings may have spotty documentation or none at all, therefore the first step is to begin documenting what you have now, starting with your entire Exchange infrastructure. Use the reporting functions of Microsoft Exchange Management Console Toolbox for Exchange Server 2007 or the Exchange Best Practices Analyzer v2.8 for Exchange Server 2003.

lts into a spreadsheet or table and use it to get a “bird’s-eye-view” of your environment. From there, you and your team will be able to see other needed documentation and the tasks that will comprise your migration plan. Document all of the changes during each phase of the process and you will have complete records of the new system.

Internal dependency of Exchange and your organization’s internal business systems may not be fully documented either, so meeting with your organization’s business systems programming (BSP) group or third-party vendors will help you grasp any additional dependencies involved with the transition. Do not forget to include backup/archive software, anti-virus, email content systems or other customized Java or API features that use Exchange Web Services (EWS).

With all of these variables, your team will need to take a dual-phased approach, similar to multiple directors working on the same motion picture. As is revealed on those DVD extras, quite often more than one director completes a scene, one for the action sequence and perhaps another for location shots that do not include the actors directly. Apply the same approach to your project by using one IT team for current system configurations and another team for building a prototype server to get the messaging team familiar with Exchange 2010’s new features. If you are short on resources, apply the same approach with what you have.

Migration Plans that Count – IT Side, User Side and Mobile User Side

During this type of project, IT teams generally focus on the system integration and deployment while the users and mobile users are presumably “carried along” as the project proceeds. This approach may lead to some failed expectations and the perception that the migration was unsuccessful. Focusing on the users will go a long way in completing a successful project (for more on a successful user experience with an upgrade, see here for a case study.) Mobile connection is equally important because more and more employees are attached to their corporate email systems via their smart phones.

If your organization is moving to a new corporate email client, such as Microsoft Outlook 2007 or 2010, your team should plan to hold quick employee introduction sessions to the new application interface. During your organization’s weekly department meetings, demonstrate new features that they can get excited about, and include videos on your company’s intranet to help with any additional training. Newer versions of Outlook will assist you better with client connectivity when the new Exchange server and the mailbox migration occur. You will reduce desktop support time and simplify user integration with the improved self-diagnostics of Outlook 2007 or 2010.

The hardest part of any project is the rollout phase. There are going to be issues with the migration that affect some users but not others. You may uncover additional unidentified network or security issues during the preparation phase, and there may be some lost data, either at a mailbox level or during the actual data migration. However, by migrating users in small groups, you will be able to focus on the successful transfer of those users without stretching your resources or increasing project costs.

In summary, it is essential to make your planning count by maintaining frequent communication, setting up email client training and providing user documentation to make the transition work in your favor for a successful rollout.

1 Microsoft® Support: http://support.microsoft.com/lifecycle/?LN=en-us&p1=1773&x=15&y=16

2 Microsoft® TechNet Disjoint Namespace Scenarios: http://technet.microsoft.com/en-us/library/bb676377.aspx

Leave a Reply

Your email address will not be published. Required fields are marked *