1. Legacy Exchange Migrations
This section covers migrations from older
versions of Exchange Server with no direct migration path. In the case
of Exchange Server 2013, this means Exchange 2003 or older. There are
still many deployments of Exchange 2003 in the business world, and so
there will be many migration project teams that need to deal with this
problem.
Before we dig in to some solutions, let's
confront the real problem: There is no way to migrate directly from
Exchange Server 2003 to Exchange Server 2013. This includes inter- and
intra-org migrations. If you attempt to install Exchange Server 2013
into an existing Exchange organization with any Exchange Server 2003
servers remaining, Exchange setup will block the installation. If you
attempt a cross-forest mailbox move from Exchange Server 2003 to
Exchange Server 2013, MRS will tell you that you are attempting to move
a mailbox from an unsupported Exchange version. Clearly this is a
problem if you are still in Exchange Server 2003, so let's review some
of your options.
Version-to-Version Upgrade
This process is exactly as it sounds. You cannot
migrate directly from Exchange Server 2003 to Exchange Server 2013, but
you can migrate from Exchange Server 2003 to Exchange Server 2010 and
then from Exchange Server 2010 to Exchange Server 2013. For most
organizations, this is a particularly painful migration path. It is,
however, the one that the Exchange product group recommends if you wish
to migrate to Exchange 2013 from Exchange Server 2003.
The migration process is made more
difficult by the requirement that you remove all traces of Exchange
Server 2003 before installing the first Exchange Server 2013
infrastructure into the organization. On the plus side, once you have
all of your mailboxes running in Exchange Server 2010, the mailbox move
to Exchange Server 2013 can be performed online, thus reducing the
migration time somewhat.
Double-Hop Inter-Org Migration
Because of pressure from
customers who did not wish to migrate from version to version, the
double-hop inter-org migration approach was conceived. This approach
relies on a resource forest with both Exchange Server 2010 and Exchange
Server 2013 installed. Mailboxes are first migrated cross-forest from
Exchange 2003 to Exchange 2010 and then immediately on to Exchange
Server 2013. This method allows for mailboxes to be migrated to
Exchange Server 2013 before Exchange Server 2003 has been totally
decommissioned, and it requires only a small deployment of Exchange
Server 2010 in the target forest. There are some downsides, however:
- It is an inter-org migration, and this brings with it the
complexities, such as having multiple
Exchange orgs, GALSync, complex mail routing, and client redirection
post-migration.
- Each mailbox must be migrated twice during each migration window, reducing migration speed.
- It enforces a resource forest model that increases complexity,
especially if you wish to deploy a hybrid solution with Office 365 at a
later date.
Migrating to Office 365
Office 365 provides Exchange Online, which
is Exchange Server 2013. It also provides a way to migrate from
Exchange Server 2003 directly to Office 365 via MRS over the Internet.
This migration process is similar to the one used for an inter-org
migration. However, the Office 365 platform provides most of the tool
and coexistence software for enterprise customers free of charge.
Migrating to Exchange Server 2010
Sometimes our advice to customers running
Exchange Server 2003 who must remain on-premises due to legislation or
other constraints is to migrate to Exchange Server 2010 as a strategic
platform. This may seem like unusual advice, but Exchange Server 2010
has proven to be a very solid platform and delivers huge improvements
over Exchange Server 2003. For some Exchange 2003 customers, Exchange
2010 represents a better target platform than Exchange 2013 because of
its easier migration path, and yet it still provides a very low total
cost of ownership (TCO), including the ability to coexist with Office
365 in a hybrid environment.
The migration tools and process
are well defined, and there are many skilled resources in the market
with expertise in these types of migrations. All major third-party
integrators have solutions for Exchange 2010, and the product remains
in mainstream support until 2015 and extended support until 2020.
2. Common Migration Problems
This section provides some insights into problems
that we have observed during migration projects and some possible ways
to help you avoid them. All successful Exchange migration projects
should be able to react well to unexpected events. As a mentor of mine
used to say, “Expect failure.” He was right—any project that cannot
deal with setbacks is destined to failure. However, our experience shows that “forewarned is forearmed,” and a little upfront planning can save you a world of pain down the line.
Failure to Get Business Support
Exchange migrations are very public projects.
Most if not all employees of an organization will be customers of the
Exchange service. This means that if there are any problems during the
migration, there is a strong possibility that you will affect someone's
working day negatively.
Frequently migration project teams use the
term “seamless” to describe a mailbox migration. Although it may be
possible to migrate the majority of mailboxes in an organization
without them noticing, there are often times when this is not the case.
Things can get interesting, especially if you have not taken the time
to engage directly with the business area that is experiencing the
problem.
IT project teams sometimes have a tendency
to plan and act within a bubble. Exchange migrations are often a good
example of this behavior. Since the migration project team does not
need any technical assistance with the Exchange mailbox migration, the
migration is tested, planned, and executed without engaging with the
business at all. Although this can work sometimes, it is our experience
that something usually goes wrong that could have been avoided by
consulting the business unit beforehand.
Working with business area representatives
prior to a mailbox migration and discussing their needs and use of the
service can pay huge dividends in the event of problems down the line.
This is especially true if contact is made in person by the migration
project team. This type of engagement is extremely common in smaller
environments. However, as the organizations with which you are dealing
get larger and larger, it becomes harder to achieve. Nevertheless, it
is in these larger environments where the payback is the greatest. If
the project team has a personal relationship and contact point with the
business area where disruptions may occur, then that issue is far less
likely to be escalated, and it can be dealt with at a project level.
Being able to deal with problems at the ground level rather than having
them escalated to senior management is without doubt a huge benefit.
Once a business area feels undervalued and
insignificant, they can make life extremely difficult. We have seen
Exchange migration projects put on hold for six months because a single
business area was unhappy about their mailboxes being migrated without
being consulted beforehand. When we became involved and made contact
with representatives from the particular business area, they had no
complaint with the migration process itself. Rather, their main
complaint was about the potential risk to service and lack of
consultation beforehand. This relationship took a long time to mend,
and the whole thing could have been avoided by a simple meeting between
the parties beforehand.
Although not always necessary, our advice
is to make contact with key business representatives, present them with
details about the proposed migration process, schedule dates, and the
expected user experience, and ask them for feedback. Determine how they
would prefer to be kept informed of progress on the migration project,
and ask if they want to be involved in the migration design and testing
signoff. Experience shows that, once involved, the business
representatives are generally very helpful and truly want the project
to be successful.
Insufficient Planning
“Failing to plan is planning to fail” is a
commonly quoted expression when it comes to project and design
planning. Certainly, it is good advice to do adequate up-front
planning, but what exactly is involved and why is it so important?
As it is for most
projects, planning is vital for Exchange migration. However, by far the
most important aspect of this is being practical. Many migration
projects have a plan that looks just great on paper or when projected
on a sparkly Gantt chart. When it comes down to implementing that plan,
however, things often begin to unravel. This is not a failure to
plan—it's because the plan itself is a failure. The tendency is for
technical resources to try to work around a mess of a plan in order to
get the job done. Sometimes this is successful, while at other times
it's not. When it is unsuccessful, it can be extremely difficult to
figure out exactly what has happened and to get back on track.
Our advice is to avoid very complex
planning charts and keep migration planning as simple and practical as
possible. Try to create a visual representation of the plan that can be
presented to business areas and the project team. Most good project
managers will maintain a complex Gantt chart for their own sanity, but
this rarely is presented to or published for the business areas.
Ideally, the plan should include all phases of the project, including
the design, testing, piloting, and business area migration schedules.
Build slack into the schedule between
phases to accommodate unexpected issues and to provide the design teams
with adequate time to rethink and resolve issues appropriately. One of
the most common mistakes we've observed is poor migration design
decisions that were made because of rushing the design phase. Exchange
migration design can be very complex, especially in large organizations.
Do not fall into the trap of thinking
everything will work just fine because you purchased an expensive
migration tool. It may simplify the migration process, but you still
need to plan, design, and test your solution to ensure success.
Incorrect End-User Expectations
Different organizations maintain different
relationships between the IT department and their end users. For some
organizations, IT will go to great lengths to make the life of the end
user as simple as possible—even if it means spending colossal amounts
of time and money to avoid the user having to perform mundane tasks.
Other organizations pursue a different path, and they embrace programs
such as allowing end users to use their own devices and welcoming
end-user interaction during a migration project.
While there is no right or wrong here, it
is important that you understand the organization's expectations before
you begin a migration project. If the end users who will undergo
migration have been pampered by IT in the past, and the migration
process that you intend to deploy requires them to perform manual
tasks, you may expect that this plan will not be well received.
Likewise, if the users being migrated are used to performing manual
tasks, then you should not over-design the migration process.
Be aware of both the implicit and explicit
expectations of the end user, and design your migration solution
accordingly. Over-designing can lead to unnecessary expense and
complexity, whereas under-designing may lead to an unacceptable
experience for the end user.
Seamless vs. Velocity
You will need to determine whether your plan is
focused on migrating everyone as quickly as possible to the new
platform in order to minimize the impact of coexistence issues, or if
end users will migrate slowly and in batches in order to minimize
disruption. This issue is not as important with an intra-org migration,
but it becomes extremely relevant for inter-org and foreign system
migrations, where coexistence problems are very likely.
Many organizations
have attempted to identify end-user relationships via delegate
permission mappings and organization charts in an effort to migrate
mailboxes in batches. The aim here is to reduce the likelihood of two
users who share mailbox data frequently from being migrated at
different times and thus experiencing disruption if they are migrated
independently. The outcome of such attempts has always been fruitless
in our experience. The problem is that the delegate permission
relationships are highly complex in nature, and it is impossible to
determine if they are in active use or not. For example, this may occur
when a user has granted a colleague access to her calendar in a former
role. The user now has a different role, but the old delegate
relationship still exists along with new delegate permissions. How do
you know which permissions are in use and which are not? Likewise,
attempting to group users by department, physical location, or project
is unsuccessful since these factors are not boundaries for data sharing.
As a general rule, attempting to group
users together is rarely successful, and it often results in a complex
migration scheduling process that leads to uneven batches of mailboxes
to migrate. The only exception to this is for shared mailboxes, where
it can be very useful to migrate the shared mailbox and everyone who
has access to it at the same time.
Our recommendation for both foreign and
inter-org migrations is to migrate as quickly as possible after a
successful pilot has been performed. Provide an emergency “quick
migration” process to migrate users who have problems accessing a
previously migrated mailbox; that is, add them to that night's
migration schedule.
The golden rule for migrations is never to
migrate users backward; always migrate them forward. For example, if
you migrated someone's mailbox inter-org but not their personal
assistant's mailbox, the assistant may lose access to that mailbox
after it was migrated. The first course of action here is to migrate
the assistant over as quickly as possible, either via a support process
that would move it immediately or add the assistant mailbox to the next
migration batch to minimize disruption.
The aim is to migrate everyone as quickly
as possible by maximizing every minute of the available migration
window. This approach will cause some temporary disruption, but it
generally provides the best overall experience. Attempting to avoid
end-user disruption entirely during an inter-org or foreign system
migration is generally an exercise in futility in any sizeable
organization.
Application Integration
IT experts have often frowned on migrating to a
new version of Exchange early in its release cycle. Many insist on
never deploying a Microsoft product prior to its first service pack,
believing the initial release will surely be full of bugs. The reality
is somewhat different these days: Exchange Server 2010 had over 20
million hosted mailboxes running at the time it was made generally
available, and it was proven to be a high quality piece of software
very early on.
Exchange Server 2013 is a major new
product release. This means that it has many more areas of significant
development than Exchange 2010. Nevertheless, the same engineering
quality processes have been used during its deployment, and it has been
tested and operated within Office 365 by customers in the Technical Adoption Program and internally at Microsoft during its development phase.
Unfortunately, the quality of the Exchange
release is not the only concern. Most organizations rely on third-party
applications that must integrate with their Exchange infrastructure.
These systems provide mobile device access, fax integration, customer
records management, archiving and compliance, antivirus and message
hygiene, and so forth. The bottom line is that a
messaging infrastructure will typically rely on many vendors and
software products, not just Exchange Server. When a new version of
Exchange is released, the vendors of each of these supplemental
products potentially will be at different phases of their own product
release cycle and may not have a version of their product that supports
the version of Exchange Server that you are deploying.
Our recommendation is to perform an early
discovery operation and make sure that all of your dependent services
and applications support Exchange Server 2013. Most vendors will share
their planned product development roadmaps with existing customers and,
in many cases, will work with customers to run and test pre-release
software. For many organizations, it is a valuable process to be able
to deploy early and potentially provide feedback for products in
development.
Compliance
Many organizations operate in areas that have
operating standards defined by a governing body. These standards often
dictate rules defining how data should be kept and for how long and,
potentially, in which country the data must remain. Exchange migrations
must be designed to meet these requirements before, during, and after
the mailbox is migrated.
Our advice is to get clear
guidance on these compliance requirements and design a migration
solution with them in mind. There is no more certain way to shut down a
migration project than to discover a breach in data compliance. Some
organizations may even be in danger of losing their operating license
if they are found to be in breach of their compliance standards. Once
you have a migration process designed, take the time to speak with the
IT risk and compliance teams and get their input about whether it is
going to meet their compliance requirements.
