Editorial Note: I wrote this for a project that ended up not working out. It's not exactly the sort of thing I'd normally post here, but I figure I put some time into it so someone might as well read it. If it's helpful to you in any way, then I guess I've done my good deed for the day. -Nathan

 

Introduction

Greetings IT professional. Since you have taken the time download this document, I am going to go out on a limb as assume you are in the early stages of planning a migration into Office 365. The good news is I have completed lots of migrations for all kinds of organizations moving to Office 365. I have very methodically and carefully made tons of mistakes on the road to Office 365. Today, I am going to explain those mistakes so that hopefully you can avoid repeating my mistakes and maybe even make a few new ones.

Migrations into Exchange Online are complex and time consuming affairs. While Microsoft has spent the four years since the original launch of Office 365 trying to make the migration process into Exchange Online more accessible, they’ve also been adding features and supported scenarios which has the effect of making migration planning more complex. These two opposing forces, the drive to bring new features to cloud services and the drive to simplify adoption and management of cloud services, are going to be realities for all of us working in IT for the foreseeable future.

In this document, I am going to help you to start planning your migration into Office 365. This is intended to be a general walk-through of the planning steps that will work for any organization migrating into Exchange Online, not a specific project plan for your specific migration circumstances.

The difference between on-premises and cloud

As you start to plan your migration into Office 365, it’s important to remember there are some very fundamental and substantial differences in the services you’re transitioning to that are going to cause you to have to do many things very differently. Many of the differences are a great benefit for many organizations, but in my experience the root cause of the issues for organizations that have failed migration projects is a misunderstanding of the differences between what they are used to and what they get from Office 365.

I’m not going to have the space in this document to fully detail every possible technical detail of Office 365 and compare that to the same on-premises service configurations. Even if I took the space to lay that all out for you, something would change by the time I got done. That is the nature of the cloud. What I can do, however, is give you the tools you’ll need to do all the discovery work before you start your migration. Once you understand how to plan your migration, and identify the points that are going to cause problems for your organization if you handle them before you get started, you’ll be golden.

So what’s the solution? Understanding what you get from Office 365, and preparing to “fill the gaps” before your migration project gets started. Far too often, I see organizations fail to understand the differences in the services they’ll be using, which leaves them unprepared to provide the services their users require.

 

Planning your migration

Before you can plan for any migration project, it is important to understand the available options. The decision points you need to focus on are identity, migration method, and your organizations business and technical requirements. Let’s take a look at these decision points, and see what sort of planning you’ll need to do.

Planning for identity

The first major decision point for any Office 365 migration is going to be how your organization will manage user identity. This choice will greatly affect the available migration methods for moving data into Exchange Online. The three possible identity management configurations are; Cloud, Managed, or Federated.

Cloud identities are those that exist only in Azure Active Directory. This option works best for very small organizations that do not have an on-premises Active Directory deployed. This could also be a viable option for a larger organization that wants their Office 365 tenant completely separate from their on-premises Active Directory.

Managed identities are those that are copied to Azure Active Directory via one of several directory synchronization tools. The possible synchronization tools include DirSync, Azure Active Directory Sync, and Forefront Identity Manager. These accounts are created and maintained in an on-premises directory service, usually Active Directory, and then copies of those account are created in Azure Active Directory. These copies are associated with the original account and set to be read-only in Azure Active Directory. Managed identities can include a synchronized copy of each users on-premises password. This password synchronization allows users to log in with the same password they use for their on-premises account without your organization having to deploy all the infrastructure required for federated identities.

Federated identities include all the features of synced identities with the addition that authentication takes place against the organizations on-premises Active Directory via Active Directory Federation Services (AD FS). Federated identities give your organization much greater control over the log-in process for user at the cost of having to maintain more server infrastructure on-premises.

For many organizations the decision about how to handle identities is a fairly simple one. Larger organizations want federated identities, mid-sized organization go with managed identities so they don’t have to deal with all the infrastructure associated with AD FS, and small organizations that don’t have on-premises Active Directory choose cloud identities.

Available migration methods

There are a number of different migration methods that can be used to migrate existing email data into Exchange Online mailboxes. The method you choose for your migration should be based on which method best fits with your organization’s business and technical requirements.

Cut-over migration is the simplest of the first party migration options. A cut-over migration is simply the process of copying your historic mail items into Office 365, and then “cutting over” your DNS records to point to Office 365. With a cut-over migration, users Outlook profile and data cache needs to be recreated, causing some level of inconvenience for the users.

Staged migration provides some, but not all, of the co-existence features of a hybrid migration without requiring as much configuration as a hybrid migration. The most important aspect of a staged migration is that it only works from an organization with Exchange 2003 or Exchange 2007 servers. This limitation is caused by the Active Directory attributes that are used for a staged migration are not present in Exchange 2010 and newer versions.

The staged migration does allow for a limited level of co-existence between on-premises mailboxes and mailboxes migrated into Exchange Online. The staged migration does not allow for Free/Busy sharing between the two systems, but it does allow for mailboxes in both systems to share the same namespace.

Hybrid migration provides the best user experience, but also requires the most complicated configuration. The hybrid migration requires either an Exchange 2010 or Exchange 2013 server to be configured as the bridge between your organization’s on-premises Exchange organization and Exchange Online. The hybrid configuration allows both organizations to appear as a single organization from your users perspective. Mailboxes can be moved back and forth between on-premises and Exchange Online without disrupting users (except mailboxes that are on Exchange 2003 servers. Those users are forced to log out of their mailboxes during the mailbox migration process.)  Because of this functionality hybrid migrations are best for testing Office 365 features. A small sub-set of your user’s mailboxes can be migrated into Exchange Online for testing without effecting anyone else in your organization. If your organization finds that Office 365 meets it’s needs, you can easily proceed to migrating more mailboxes at whatever pace works for your organization. If during this testing period you find that Office 365/Exchange Online is not the right fit for your organization, moving mailboxes back on-premises is just as easy and painless as the initial migration into Exchange Online.

3rd party migration tools can be used to “fill in the gaps” between the existing 1st party migration options. If you find that the three 1st party migration options do not completely meet your organization’s requirements, there may be a 3rd party tool that fits your needs. Often times migrations from non-Exchange messaging systems and hosted Exchange platforms are examples of migration projects that use 3rd party migration tools.

Whatever migration method you end up choosing for your organization it’s very important to understand how the process is going to work, and where the possible failure points are going to be before you get started. To understand those failure points, you need to understand what your organizations priorities are. These organizational priorities are best defined as business and technical requirements.

Business requirements

Defining business requirements before starting any migration project is a vital step for success. If you don’t clearly define your requirements, how can you know if your migration was successful or not?

Defining business requirements for a migration project can be difficult. Business requirements are pretty much whatever the managers in charge of your migration project says they are, and I’ve had some pretty interesting requirements given to me. Some typical business requirements are;

Timeline – the business may require that your project start and/or be completed by a specific time. This may be because of a datacenter move, or an Enterprise Agreement renewal date. For whatever the reason, sometimes migration projects need to be completed within a tight timeframe. The timeline for a migration project can affect the feasibility of specific migration types.

Budget – Always a major concern for any project. The available budget can have a great effect on ever other decision that is made during the migration project. 3rd party migration tools and consultants can be fairly expensive. Conversely, Microsoft has a variety of funding options that can be used to offset or sometimes completely cover the costs associated with a migration project.

Service availability – The different possible migration methodologies mean that different email services will or will not be available during the migration. A Cut-over migration requires a brief period of total outage, and a staged migration requires some period of reduced functionality.

Change management – Each organization has its own change management requirements. This requirements may dictate a specific set of protocols be followed before and during any migration project. This protocols can have a significant impact on which migration methodologies are chosen.

Specific features – While features generally fall under the heading of technical requirements, in some cases a specific feature requirement can affect a business process in a way that moves that requirement under the category of a business requirement.

User communication – An organization’s policies around communicating changes in IT infrastructure to its user community may affect the choice of migration methodologies.

Off boarding – Some organizations require a testing, or user acceptance, period before moving the entire organization into a new platform like Office 365. This requirement can affect the migration methodologies in that hybrid migrations make it very easy to move a single mailbox from on-premises Exchange to Exchange Online and back again. With cut-over migrations the entire organization has to be move all at once, and migrating back to on-premises Exchange is just as difficult if not more difficult than the original migration into Office 365.

Technical Requirements

Defining technical requirements is, at least in my experience, much easier than defining business requirements. Technical requirements tend to be much more straight forward. Some examples of technical requirements you may define for your migration project are;

Historic email – For most migration projects, organization want to move all existing data into the new platform. However, for some migrations there are requirements to limit the amount of data migrated. This may mean limiting the data migrated to a specific amount per user, or only migrating data from a specific time frame.

Calendar and contacts – Hybrid migration also move calendar and contacts from the on-premises mailboxes, but IMAP migrations do not. It’s important to understand what data is moved by the migration methodology you choose.

Archive – Migrating data from 3rd party archive solutions can be a significant challenge. If your organization’s 3rd party archive solution does not integrate with Exchange Online, or if your organization decided to take advantage of Exchange Online archiving there can be significant challenges in getting that data into Exchange Online.

Distribution groups – When performing any migration method that uses DirSync, or any other Active Directory synchronization tool, users lose the ability to manage distribution lists within their Outlook clients after their mailboxes have been migrated into Exchange Online.

Public Folders – Public folder migrations are a considerable added level of complexity to a standard Exchange Online migration. Hybrid migrations do allow for mailboxes that have been migrated from on-premises to Exchange Online to access public folders hosted on your organization on-premises Exchange servers. Once all mailboxes have been migrated into Exchange Online a separate effort can be undertaken to migrate the public folders into Exchange Online.

Picking your migration method

Once you understand the available options and have defined your requirements it’s time to put that information to work and decide on your migration method. Generally your organization’s requirements will limit your choices to a sub-set of all the options. I find that often a firm business requirement ends up pointing you in a specific direction.

Executing your migration

Once you have considered all your options and decided on a migration plan, it’s time to execute. Successfully completing a migration project into Office 365 can be a daunting task. Even a well-planned migration project can quickly go bad if you lose the confidence of your organization’s management and user communities. The quickest way to lose confidence in your migration project is unexpected services interruptions.

Your migration methodology may include planned service outages, and in most cases user communities are accepting of these outages. Unplanned outages, however, are rarely tolerated for long. It is vitally important for your migration plan to include a detailed analysis of any possible service interruptions, and mitigations for these interruptions.

Office 365 SLAs

One of the greatest selling points for Office 365 is Microsoft’s 99.9% finically backed service level agreement. This SLA gives organizations confidence that they can rely on Office 365 to avoid the outages that can occur when these services are run from traditional on-premises servers.

While Microsoft consistently reports meeting and exceeding this 99.9% uptime SLA, this does not apply to data and services until your migration project is complete. Whatever your planned migration methodology is, it’s important to remember that Microsoft cannot assure any availability until your migration project is successfully completed.

Maintaining your Exchange Online deployment

So you completed you’ve migrated some or all of your user’s mailboxes into Office 365. Time to send the consultant home, fire your IT staff, and never again think about managing email systems, right? Nope. Moving to Office 365 might mean you don’t have to worry about physical servers anymore, but it absolutely does not mean you don’t have to manage your email systems. Managing Exchange Online is different than managing Exchange on-premises, but it’s still a system that needs your attention.

Keeping up-to-date

Maybe the biggest new challenge after a migration to Office 365 is keeping up-to-date with the high pace of changes to the service. Microsoft is now a cloud first business, and this means that new features all their software is going to come to the cloud services first. Your administrators, users, and on-premises server infrastructure all need to keep up-to-date with changes in Office 365.

Administrator training includes keeping up with new features as they are released into the Office 365 service. The Office 365 roadmap is a great resource for administrators to learn about new and upcoming features in Office 365.

User training is an important aspect that many organizations forget about after a migration to Office 365. As the services within Office 365 are upgraded, it is important for IT departments to have a user training plan in place.

Hybrid infrastructure refers to the on-premises servers that maintain some level of connection to Office 365. This might be your on-premises Exchange server, SharePoint server, Lync servers, directory sync servers, or AD FS server.

Maintaining archived data

One of the greatest benefits of migrating to Office 365 is the nearly unlimited space both in mailboxes and for file storage within the service. Users with an E3 license get 50 GB mailboxes, plus an unlimited archive mailbox. In addition to this huge amount of email storage space, Microsoft is in the process of enabling unlimited file storage for all users within OneDrive for Business.

With all this space for data storage, it is important for your organization to understand any applicable compliance rules. HIPPA, Sarbanes-Oxley, Grahm-Baily-Leach, PCI, and other standards can have significant impact on what data your organization is required to keep and for how long your organization is required to keep that data. A complete understanding of your organization requirements, and a plan for managing this data is absolutely essential.

Backup and Recovery

One of the foundation design factors of Exchange Online is Exchange Native Data Protection. NDP is a set of features that is designed to keep Exchange mailboxes available through all kinds of failures. Any single mailbox within Exchange Online is replicated to multiple servers within multiple datacenters.

This native data protection means that Microsoft can operate Exchange Online without traditional backups. This lack of traditional backups mean that if a user deletes items and does not realize they are gone during the limited single item retention period, those items are gone forever. Your organization needs to have a well-developed plan for user training, and if necessary a 3rd party solution to maintain backups outside of Office 365.

Spam and Antivirus protection

Microsoft’s solution for spam and antivirus protection for mailboxes within Office 365 is Exchange Online Protection. EOP sits in front of all mailboxes within Exchange Online. A careful examination of the features and controls within EOP is warranted.

Putting it all together

The key to making any migration project successful is a complete understanding of the technology involved. While Office 365 is an excellent offering that can greatly improve the service offered by many organization’s IT department, there are still places within a migration project where critical errors can hurt your organization’s experience. In my experience those problem areas are

• A lack of understanding of the differences between the on-premises and cloud solutions

• A failure to prepare the user community for the migration

• The loss of integration with 3rd party services that business practices have come to depend on

Careful planning and a close examination of your organization’s requirements compared to the features available within Office 365 are the best ways to ensure your migration project ends up a success.