Best Practices for Exchange Server Migrations, Part 2
In the first article in this series, I outlined three steps that I think are essential to the Exchange 2007 migration process. In this article, I want to continue the discussion by providing you with some more steps in my migration best practices.
Step 4: Focus on the Clients
Your users aren’t going to get the full benefit of your Exchange 2007 migration unless they are running Outlook 2007. An upgrade to Office 2007 isn’t an absolute essential, but it is a good idea, and pretty much every company that I have assisted with the migration process has adopted Office 2007 as a part of that process.
One thing about Office 2007, and Outlook 2007 in particular, is that you don’t have to wait until you perform the Exchange Server migration to deploy it. In fact, I personally use Outlook 2007, even though my mailbox is on an Exchange 2003 server.
One of the best things that you can do to ensure a smooth migration is to go ahead and get your users trained on Office 2007, and then deploy it. Training is important, because the Office 2007 user interface is quite a bit different from the one used by previous versions of Office. If you are not familiar with these differences, then you can see what the Outlook 2007 user interface looks like in Figure A.
Figure A Outlook 2007 has a different interface than its predecessors used.
The reason why I suggest moving forward with the upgrade to Office 2007 is that it will give your users time to get used to the new version of Outlook before you actually perform the Exchange Server migration. That way when you do eventually migrate the user’s mailboxes to Exchange 2007, the change won’t be quite so dramatic.
I also recommend going ahead and putting Outlook 2007 in place ahead of time because Outlook 2007 contains an automatic discovery mechanism that will automatically detect the location of the user’s Exchange mailboxes. This helps to simplify things after the migration since Outlook will be able to automatically detect the mailbox’s new location.
Step 5: Research Potential Side Effects
The next thing that I recommend doing is to take some time to research some of the side effects to bringing Exchange 2007 into your existing Exchange Server organization. There are a number of Exchange 2000 features that were discontinued when Microsoft created Exchange 2003, and there are also a number of Exchange 2003 features that Microsoft dropped in Exchange 2007. In most cases, you can continue to use the discontinued features by leaving a legacy Exchange Server in the organization, but that is not always the case. Some legacy Exchange features are completely incompatible with Exchange 2007. You can find a list of the discontinued and deemphasized Exchange 2007 features here.
Step 6: Perform a Pilot Deployment
The next step that I would recommend performing is a pilot Exchange 2007 deployment. Ideally, you should perform the pilot deployment in a lab environment. The lab should be configured to mimic your current domain controller and Exchange Server configuration. You can then experiment with installing Exchange 2007, and moving mailboxes to the Exchange 2007 server. This will allow you to get a feel for the migration process before you have to perform it in a production environment, and may also help you to spot any potential gotchas ahead of time.
If your company does not have the resources for a full blown lab deployment, then I recommend going ahead and bringing an Exchange 2007 server into your production environment (assuming that you have done the proper planning and made backups). You can then either set up some dummy mailboxes to experiment on, or you can pick some users with non critical job functions and migrate their mailboxes as a part of a pilot deployment.
Step 7: Move Forward with the Migration
By now you should be ready to move forward with a full blown migration. There are two pieces of advice that I would give you prior to the migration though. First, you should make a full system state backup of your existing Exchange Servers and your domain controllers prior to the migration.
The other thing that I would advise is scheduling some down time if possible and running a database integrity check on your existing Exchange servers before you start migrating mailboxes. This can step is a pain, but it can save you from a failed migration related to unexpected database corruption.
Having a roadmap is essential to the migration process. This article series has laid out the steps that you need to perform in order to have a successful migration.
Recent Exchange Forum threads
Got a question? Post it on our Exchange Server Forums!
More in Exchange Server
M365 Changelog: Get-AdvancedThreatProtectionDocumentReport and Get-AdvancedThreatProtectionDocumentDetail to be retired
May 24, 2022 | Petri Staff
M365 Changelog: (Updated) Microsoft Defender for Office 365: Updates to URL Protection Report
May 24, 2022 | Petri Staff
M365 Changelog: Safe Links Global Settings Migrated to Custom Policies
May 20, 2022 | Petri Staff
Microsoft to Ship Some Exchange Server Security Updates in .EXE Packages
May 11, 2022 | Rabia Noureen
M365 Changelog: Exchange Transport Rule Report moving to the new Exchange Admin Center (EAC) from the Security and Compliance Center
Apr 22, 2022 | Petri Staff
Hive Ransomware Group Attacks Vulnerable Microsoft Exchange Servers
Apr 22, 2022 | Rabia Noureen
Most popular on petri