Migrating mail systems can be confusing and time-consuming. That said, I am going to simplify the process of migrating to Exchange from a third-party mail system into eight basic steps.
(For more detailed instructions, you can download Microsoft's white paper here).
Step 1: Plan your migration.
If you work in a small organization with a single mail server, your planning will be minimal because you will likely be migrating everything at once. In larger organizations with many different servers, however, you will have to design the Exchange infrastructure. For example, where will the servers be placed? Who will have mailboxes on which servers? Which servers will be migrated first? How will the Exchange Servers co-exist with your existing mail servers during the transition period? These are all issues that need to be taken into account during the planning phase.
Step 2: Document your existing infrastructure.
At first it might seem pointless to document your old mail system, but it really does help with the migration because it will help you in the planning phase. You will want to make note of things such as how the servers are connected to the Internet, and how the servers are connected to each other. You will also want to consider whether the clients have to do anything special (such as pass through a fire wall) to access the mail servers.
Step 3: Plan some more.
In step 3, you are going to be planning a migration strategy based on the information that you have compiled. Your main goal is to have a minimum impact on the end users. There really isn't a way of migrating to Exchange with no impact on the users, but you will want to make the inconvenience minimal. If you have multiple mail servers, I recommend migrating the one with the fewest mailboxes first. By doing so, you can work out the kinks before you attempt to migrate large numbers of mailboxes.
Step 4: Deploy the new Exchange organization.
In this step, you will install at least one Exchange Server and verify that the server is functioning correctly. It would be idea if you could deploy all of your Exchange Servers at this stage of the process. However, realistically you will probably be reusing some of your old hardware, which makes a full-scale Exchange deployment at this stage impossible.
Step 5: Establish connectivity between the Exchange organization and your existing mail system.
This isn't as difficult as it sounds. Exchange includes mechanisms called gateway connectors. These gateway connectors link the Exchange directory to the directory found in your existing mail system (assuming that your existing mail system is supported). Exchange Server 2003 includes connectors for Lotus Notes and for Novell GroupWise; Exchange 2000 offers connectors for Microsoft Mail, Lotus CC Mail. If a connector doesn't exist for your mail system, you might be able to use a third-party migration utility.
Step 6: Deploy either Microsoft Outlook or Microsoft Outlook Web Access.
This might seem a little premature since you haven't actually migrated anything yet, but think about it for a second. If the users do not have a copy of Outlook or instructions for accessing Outlook Web Access, then they will have no e-mail access once the migration completes. If you go ahead and deploy Outlook now, then your users will have Outlook and their current mail client software readily available. They can use their existing software for right now and then as soon as the migration is complete, they can immediately begin to use Outlook. Users won't have to wait around for the IT department to come and connect them to the new mail server.
Although it isn't a part of Microsoft's eight migration steps, I also recommend taking the time to start training users on using Outlook, or at least get them some easy-to-follow instructions. This will help reduce the number of phone calls that the help desk gets after the migration is complete.
Step 7: Move users and port collaborative applications.
As you will see in the Exchange 2003 Interoperability and Migration Guide, moving mailboxes is easy once the connectors are established. The tough part is porting collaborative applications. Exchange offers its own alternatives to many collaborative applications (such as a scheduler and a contacts list). If you have more advanced applications, though, you may need to find out if an Exchange version is available.
Step 8: Decommission the old mail servers.
If you have enough hardware at your disposal to have both mail systems running simultaneously, then I recommend waiting for a week or two to take the old mail system offline. That way you will have your old system to fall back on should something unexpected occur. Normally, however, hardware is an issue and your old mail servers will be decommissioned shortly after migration so that they can be reused.
As you can see, the migration process itself tends to be fairly simple, as long as you have done the appropriate planning. Planning is by far the most important step in a migration to Exchange. As long as you have taken your time and planned out every detail of the migration, it should go smoothly. If you are uncomfortable performing the migration yourself, there are several good third-party migration programs that can greatly simplify things.
Editor's Note: "Exchange Admin 101" is a new category of tip that we created for the Exchange newbie. This regularly featured tip will discuss a topic of particular importance to the new Exchange admin or to the admin who has upgraded to a new version of Exchange and wants to learn the basics.
If you have suggested topics for Exchange Admin 101 tips, please send them along to editor@SearchExchange.com.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.
