Before getting too far into the tools and
process of migrating to Exchange 2007, it is important to understand,
from a high level, the strategy on how to migrate to Exchange 2007. The
migration strategy could be as simple as effectively moving everything
from Exchange 2000 Server or Exchange Server 2003 straight in to
Exchange 2007 without making drastic modifications. Or, it could mean a
very complex Exchange environment restructuring is performed as part of
the migration process.
It is not required
to completely restructure Exchange as part of the migration. In fact,
if Exchange 2000 or 2003 is working fine today, then just a simple
migration is all that is required. Possibly, the organizational
structure worked fine for years for the organization; however, a
redesign is now needed because of a change in how the organization does
business. These types of changes can make the migration process more
complex as are migrations that take place from a messaging system other
than Exchange 2000 or Exchange 2003. Some of the migration changes are
things that could take place before or after the migration to Exchange
2007.
Simple Migration from Exchange 2000 Server and Exchange Server 2003 to Exchange Server 2007
For
organizations that have a working Exchange 2000 or Exchange 2003
environment that is happy with the architecture and operation of their
Exchange environment and simply want to move to Exchange 2007, the
migration process is a relatively simple and methodical process. In a
condensed format, the process involves replacing Exchange 2000 or
Exchange 2003 front-end servers with Client Access servers, replacing
bridgehead servers with Hub Transport servers, adding new Exchange 2007
Mailbox servers, and “dragging and dropping” the data from the old
server, or servers, to the new server, or servers. It’s not quite that
simple because there are several preparation steps that need to be
conducted, a handful of test procedures that can assist the
organization in the event of a migration failure that requires rolling
back during the migration process.
Restructuring Exchange as Part of the Migration to Exchange Server 2007
For
organizations that have undergone business changes since the
installation of Exchange 2000 or 2003, or that have an Exchange
environment that is not architected properly for the current and near
future business environment of the organization, they might
choose to restructure Exchange as part of their migration to Exchange
2007. The restructuring can occur with Exchange 2000 or 2003 prior to
the migration, the restructuring can occur during the Exchange 2007
migration, or the restructuring can occur after Exchange 2007 has been
put in place.
The deciding factor on when
the restructure occurs depends on the effort involved to perform the
restructuring. Some organizations will consolidate servers as part of
their restructuring process. This is a simple process that can usually
be done during the migration where, for example, several Exchange 2000
or 2003 back-end servers are consolidated into a single Exchange 2007
Mailbox server. As mailboxes are moved from the old Exchange to the new
Exchange, they can be moved from multiple systems to a single system.
This restructuring is easy to do as part of the migration process.
Some
migration processes are more complex, for example, if the organization
wants to completely collapse remote site servers and bring all of the
servers into a centralized Exchange environment model. From an Exchange
perspective, collapsing sites is one of the restructuring options that
can be done as part of the migration; however, the challenge is
typically trying to move large amounts of email over a wide area
network (WAN) connection. If a remote site has several gigabytes or
even tens or hundreds of gigabytes, it is unrealistic to migrate that
amount of mail over a WAN connection as part of a migration process. In
many cases, the actual server, hard drives of the server, or backup of
the databases are physically brought into the centralized data center,
and the data is migrated in the data center. Although a logistical
shuffle to physically move servers or data during the migration
process, this is not an insurmountable process than trying to move
large sets of data across a slow WAN link connection.
The
more complex restructuring model is required when an organization wants
to add some sites, remove some sites, consolidate other sites, and
completely redo sites that already exist. The choice of when to do the
changes depends on the length and scope of the Exchange migration. If
the scope and goal of the migration is to do the restructuring in the
Exchange migration project, plan the process and proceed with a
restructuring of Exchange as part of the migration to Exchange 2007.
However, if the restructuring would be nice to have, but not
significant to the scope of the project, you might choose to
consolidate servers and migrate to Exchange, and then perform the
restructuring after Exchange 2007 has been installed.
Migrating to a Brand-New Exchange Server 2007 Organization
Another
method for migrating to Exchange 2007 is one where a brand-new Exchange
2007 server is built from scratch, and then data is moved into the new
Exchange environment. An organization might choose to use this method
if there are significant problems with their existing Exchange 2000 or
2003 environment, or if the configuration of their existing Exchange
environment is not ideally suited for Exchange Server 2007. This is a
significant migration task and requires serious consideration regarding
whether this is the best option. Instead, perhaps the Exchange 2000 or
2003 environment can be cleaned up to a state where a simpler migration
could take place.
When
building a new Exchange 2007 environment, data can be exported and
imported from an old Exchange environment to a new one; however, there
will be many user interruptions and impacts. At a minimum, the Outlook
profiles on user systems will need to be changed to point the user to a
completely new Exchange server. Anyone with offline stores or
cached-mode Exchange configurations will need to completely rebuild
their offline Outlook databases. Furthermore, in cases where the new
Exchange has a completely new organizational structure, links such as
appointments or meeting requests will be disconnected from the person
who invited them to the appointment because the new calendar might have
different usernames, site configurations, and so on.
In
addition, with a clean installation of Exchange 2007, the organization
will not be able to add back in an Exchange 2000 or Exchange 2003
server. Old Exchange server versions are only supported in an Exchange
2007 environment that was migrated from the old version to the new
version of Exchange. When Exchange 2007 is installed from scratch, none
of the legacy backward-compatibility tools are installed or configured
to work.
So, a brand-new Exchange 2007
installation is a drastic move for an organization that already has
Exchange 2000 or 2003. If the organization can do one of the migration
methods and then clean up the model after migration, it would be easier
to perform the migration.
Migrating from Exchange Server 5.5
A
migration from Exchange 5.5 to Exchange 2007 is not directly supported
and requires a migration first from Exchange 5.5 to Exchange 2000 or
from Exchange 5.5 to Exchange 2003. After successfully migrating to
Exchange 2000 or Exchange 2003, the organization can then execute the
migration to Exchange 2007.
Migrating from Lotus Notes, Novell GroupWise, and Sendmail
Yet
another migration scenario is when an organization has an existing
non-Exchange environment, such as Lotus Notes, Novell GroupWise, or
sendmail. The process of migrating from a
non-Exchange environment is one that requires tools to migrate user
email, calendars, contacts, shared folders, and other information
stored in the old email system to Exchange 2007. This type of migration
usually starts with the installation of a completely clean Exchange
2007 environment in which user data is then migrated into the new
environment.
Migrations Involving a Limited Number of Servers
Beyond
just migrating from one version of messaging to Exchange 2007, the
destination environment of Exchange 2007 can depend on the size and
architectural structure of the resulting Exchange 2007 environment. For
a small organization, the destination Exchange environment could be a
single server where the various Exchange 2007 roles are all on a single
system. If there is no need to add additional server systems to the
environment, then having a limited number of servers and placing server roles on a single system is easy to do.
The
Hub Transport, Client Access, and Mailbox server roles of Exchange 2007
can all be placed on a single server; however, if the organization
wants to add an Edge Transport server role to the organization, the
Edge Transport server needs to be on a separate server. This is done
for security purposes to isolate the Edge Transport server from other
servers in the Exchange 2007 organization that host production data.
Migrations Involving a Distributed Server Strategy
For
larger organizations, the various server roles will likely be applied
to systems dedicated to a particular server role for purposes of
performance and scalability. In many cases, a larger organization will
already have existing roles for front-end and back-end servers, as well
as bridgehead servers. In these larger environments, assuming that
separate servers will be retained, the Exchange 2007 server roles will
replace the existing Exchange 2000 and Exchange 2003 server systems
with a similar distribution of server systems.
When migrating to an Exchange 2007 environment with individual servers, the process of migrating involves the following:
1. | Migration of the Client Access server roles first
|
2. | Followed by the migration of Hub Transport server roles
|
3. | Then the installation of Mailbox server roles
|
4. | And finally the installation of servers such as Edge Transport servers and Unified Messaging servers, if desired |
