Office 365 provides great features, capabilities, and functionality to empower your business to keep pace with the demands of doing business today. In this overview of carrying out an Office 365 migration, we will look at several key aspects of migrating to the Office 365 SaaS environment.
However, a migration from on-premises to the cloud is not a task to be taken lightly. There are many different aspects of migrating to the public cloud that need to be considered. This includes evaluating the decision to migrate to the cloud itself. Is it right for your business? What about the technical aspects of pulling off such a migration? There is much to be considered.
- Evaluating the decision to migrate to Office 365
- Choose the right identity model
- Determine the type of migration and execution
- Dealing with email archives and PST files
- Third-party tools to assist with your Office 365 migration
- Post migration adoption of Office 365
- Wrapping Up
You may say, “we’ve already evaluated the migration to the Office 365 public cloud, and we’re doing it to save money”.
While this may be true in most cases, some have found the cloud may cost more money than on-premises infrastructure. It is important to understand that cloud environments shift spending from a capital expense to an operational expense.
One advantage of this change is that it can certainly make expenditures more palatable. Capital expenditures for new physical servers, network equipment, and datacenter infrastructure required to run backend systems can be major. However, with the cloud, you are in a simple “pay for what you use” model where you are charged for the resources you consume.
Office 365 licensing
With Office 365, this comes down to a “per-user” licensing where you are paying for an Office 365 license for the users that are making use of Office 365 resources. The nice thing about Office 365 licensing is that you can mix and match your licensing. If some users need only E3 licensing and only a select few need E5 licensing, you can mix licensing to accommodate the needs and features that are required by your user base.
The overall point to be made is the decision to migrate to the cloud needs to be made after careful consideration. The decision that is right for one business may not be the right decision for your business. Evaluate your needs carefully and in light of real business requirements and what you are hoping to accomplish by a cloud migration.
Making assumptions on the supposed benefits or cost savings can result in a migration that brings about unexpected “gotchas” or costs. You want to give due diligence to your migration from a business strategy and overall “big picture” perspective.
Perhaps the most important decision that you have to make from the beginning is choosing the right identity model. How are your users going to be authenticated to your Office 365 environment?
For many enterprise environments, the on-premises identity and authentication services are handled by Microsoft’s Active Directory Domain Services. Your end goal when you migrate to Office 365 is to have a seamless experience for your end-users who may be authenticating on-premises and also accessing resources in Office 365.
Choosing the right identity model is absolutely essential to a successful Office 365 migration. This is of key importance as it affects many different aspects of your cloud deployment with Office 365. This includes where authentication takes place, the amount of infrastructure needed on-premises for authentication to be successful, and the behavior and features of authentication depending on the mechanism chosen.
Microsoft offers four distinct identity models when migrating to Office 365. In each model, the mechanism for authenticating your end-users is different. Each model has strengths and weaknesses that need to be considered before settling on the right model for your business.
The four identity models for Office 365 include the following:
- Password Hash Synchronization
- Pass-through Authentication
- Active Directory Federation Services (ADFS)
Let’s look at each of these in a bit more detail and cover the pros and cons of each solution in regard to their use in your Office 365 authentication architecture.
The cloud-only authentication mechanism is the easiest to deploy and requires the least amount of infrastructure. This is because no synchronization takes place between on-premises and the Office 365 cloud. All authentication of your user’s access Office 365 resources takes place in the cloud via Azure AD. There is no connection from the Azure AD environment in this model to your on-premises Active Directory infrastructure. This makes the process easy to implement and maintain since there are very few moving parts.
Why might you not want to use the cloud-only approach to authentication? With cloud-only, your user accounts and passwords are not synchronized. This means that your end-users need to remember their password both on-premises and in the Office 365 cloud for access. For many that currently operate with on-premises Active Directory Domain Services authentication, this may not be a desirable means of authenticating your users to Office 365 due to the potential for login disparity.
Password hash synchronization
Many organizations find that cloud-only authentication does not satisfy their business requirements. They need to have the ability to have the same set of credentials to authenticate whether users are on-premises or accessing resources in the cloud. In this case, setting up some type of synchronization between on-premises Active Directory environments with the Azure AD-backed Office 365 environment is required.
Microsoft has provided several mechanisms to do this. The first is the Password Hash synchronization mechanism. The password hash synchronization authentication mechanism is one of the older technologies that has been around for some time to synchronize on-premises user credentials with the Office 365 cloud.
Password hash synchronization uses a Microsoft tool called Azure AD Connect. Azure AD Connect is a software component that is loaded on-premises that connects to both the on-premises Active Directory environment and the Office 365 tenant environment. It then synchronizes the password hash between the on-premises Active Directory environment and the Office 365 environment.
Configuring Azure AD Connect.
Many make use of password hash synchronization as it is easy to configure and requires very little in the way of on-premises infrastructure. You can also make use of multi-factor authentication with Azure.
A few things to note with password hash synchronization:
Unless manually synchronized, Azure AD Connect synchronizes accounts based on an interval of time. Unless you manually run the synchronization process, you have to wait for each synchronization interval to run before the accounts are synced up
With password hash, logon restrictions are not synchronized
Let’s take a look at a newer form of password synchronization that solves some of the challenges with password hash synchronization.
Microsoft has released a new solution for synchronizing passwords between on-premises and Office 365 cloud called Pass-Through Authentication. This is a new password synchronization mechanism that provides enhanced capabilities when compared to password hash synchronization.
In terms of functionality, it is a “happy medium” between password hash synchronization and Active Directory Federation Services (ADFS). With pass-through authentication, user accounts and passwords are synchronized between on-premises and Office 365.
However, when a user authenticates to Office 365, the authentication request is sent back down to the on-premises environment. There are advantages that come with this type of implementation of password authentication. These are very similar to Active Directory Federation Services.
- More control over your authentication solution
- The authentication process happens on-premises instead of in the cloud
- Account changes are reflected immediately (account disabled, logon restrictions, etc.)
- A simpler implementation when compared to ADFS
It is important to note that the availability of authentication is dependent upon you when using the pass-through authentication mechanism. This generally involves setting up multiple pass-through authentication agents to provide high-availability.
Active Directory Federation Services (ADFS)
With the new options Microsoft has introduced, like pass-through authentication, Active Directory Federation Services (ADFS) is becoming a little less used as many environments simply do not need the extra features and complexity added by ADFS.
ADFS provides a number of features and capabilities that provide a great deal of control and customization over the authentication process. This includes:
- The ability to filter users based on client location
- Customization of the look and feel of the login page (custom branding)
- Single Sign-On capabilities
- Immediate security features like account disablement and logon restrictions enforced
- Third-party multi-factor authentication
There are downsides to choosing ADFS to authenticate your end-users. These include:
- Your authentication mechanism totally relies on your on-premises infrastructure
- ADFS can be complicated to configure and equally difficult to troubleshoot if something goes wrong
Consider the identity model carefully
As you can tell, choosing your identity model is an important decision to make. It can either ease the migration to Office 365 or create difficulties if the wrong identity model is chosen for the features or manageability needed. There are generally tradeoffs with each identity model and authentication mechanism. For most environments, some type of synchronization is needed.
Depending on the complexity, skill with managing various infrastructure, and features that are needed, you will need to choose between password hash and pass-through synchronization or using full-blown Active Directory Federation Services.
Be sure to understand the requirements of each synchronization mechanism, along with the pros and cons of using each type of password synchronization/authentication mechanism.
After you have determined the type of authentication model you want to implement and how you want your identities to be verified between on-premises and the cloud, it must be determined how you want to carry out the actual migration itself. There are four distinct migration strategies that can be used to migrate users to Office 365. These include the following:
Each of these distinct migration strategies, like the identity models, have advantages and disadvantages. Let’s take a look and see how each of these migration strategies work.
The Cutover migration is one that involves migrating all mailboxes, contacts, and distribution groups from the on-premises Exchange environment to Office 365 in one fell swoop. You can think about the cutover migration as being like “throwing the switch” and switching from on-premises to Office 365 at one time.
The cutover migration can essentially be carried out with all versions of on-premises Exchange to the Office 365 environment. However, it is important to note, Microsoft sets a limit of around 2000 users for cutover migration. Realistically, according to Microsoft, it may be much more feasible to expect to use cutover migrations for around 150 users or less.
Users are not interrupted by the cutover migration process. Incremental sync runs every 24 hours after initial synchronization and can run up to 90 days. Once the cutover is ready, DNS records are changed, and clients are changed to point to Office 365 Exchange Online mailboxes.
- All users are migrated in a single maintenance window
- Supports all Exchange versions
- Works well with small organizations
- Migrates mailbox items and distribution groups
- Does not realistically support over 150 users (even though 2000 is the limit)
- It is an “all or nothing” migration process
- It does not handle changes in the source mailboxes very well
- It is a one-way migration
- Does not migrate public folders or dynamic distribution groups
- You can’t use directory synchronization initially so users must have new passwords distributed to them
- You cannot pre-stage user accounts in Office 365 as this has to be done with the cutover migration itself
- Outlook mail profiles of all users must be reconfigured to connect to the Office 365 environment
- Can mean a huge amount of network traffic since users will have to synchronize all mail with mobile devices and others
A staged migration is only supported with Exchange versions that do not support the hybrid migration. This is only supported with Exchange 2003 and 2007. These are both end of life products, so most likely; stage migrations will not typically be one that you will see used that often. Since staged migrations are limited, so consider using hybrid instead if possible.
If you are running Exchange 2010 or higher, you can’t use a staged migration and will want to use the hybrid migration. With the staged migration you create migration batches. Mail forwarding to Exchange Online is configured by the migration process. When a batch is completed, you run a conversion script to turn mailbox users into mail-enabled users.
When all migration batches complete, you can remove directory sync and exchange server to go cloud-only if you want. Keep in mind though the goal with a staged migration is to migrate fully to the cloud and not establish a permanent hybrid connectivity scenario.
- Supports up to 2000 users
- Allows moving mailboxes gradually
- Does not support Exchange 2010 or higher
- Interrupts users at the beginning of the process
- One-way migration only
- Users must create new Outlook profiles
Staged Migration workflow as outlined by Microsoft (image courtesy of Microsoft)
The hybrid migration is supported by versions of on-premises Exchange that support hybrid connectivity. This includes Exchange 2010 and higher. It is interesting to note that this can include mixed organizations with Exchange 2003 or Exchange 2007 servers that have an Exchange 2010 server that can establish the hybrid connectivity.
Microsoft even offers a free “hybrid-only” license for Exchange 2010, 2013, and 2016 that allows establishing hybrid connectivity for this purpose only as long as the server does not host any mailboxes. There are no minimum or maximum numbers of users that can be migrated using the hybrid process. Another key point to note – this hybrid license is not available for Exchange 2019.
When you use the hybrid approach, you set up directory synchronization using Azure AD Connect. It establishes a true hybrid mail flow. This includes a unified GAL, cross-premises free/busy data, and unified administration. It is the only option that supports offboarding mailboxes from Office 365.
Office 365 hybrid configuration with on-premises Exchange (image courtesy of Microsoft)
- Provides the best end-user and administrative experience, best features, and most options when in the hybrid configuration
- Provides online mailbox move and minimal end-user interruption
- Outlook mobile device profiles redirect to Exchange online automatically
- The only option that allows offboarding Office 365 users back to on-premises Exchange
Allows both short and long-term hybrid configuration scenarios where hybrid configuration may be permanent
Must have an Exchange 2010 or higher Exchange server in the mix for establishing hybrid connectivity
Removing on-premises equipment after a hybrid move can be very difficult, depending on the authentication model chosen
IMAP migrations make use of IMAP protocol to allow migrating email from non-Exchange systems. This may include email housed in Gmail, Yahoo, and others.
- This is really only for non-Exchange systems that require using the IMAP protocol to get email items out of the system
- You must create accounts and mailboxes in Exchange Online automatically
- You must have the individual account passwords for each account
- It can only migrate email content
- It is limited to 500,000 mail items
- Limited to 50,000 total mailboxes although this is far beyond what most will feasibly be able to use it for
- It is subject to being throttled by the source email provider’s servers
Email archives by way of Exchange email archive mailboxes as well as PST files that host old email data are very common in most enterprise environments running Exchange Server today. First, let’s look at email archiving. These may exist in the form of:
- Exchange archive mailboxes
- Journal archives
- Third-party email archive systems
Microsoft Exchange native archiving methods by way of Exchange archive mailboxes can be migrated directly to Exchange Online in hybrid environments. Optionally, you can migrate the archive mailbox before or after the primary mailbox it is attached to. One thing to keep in mind with migrating this data is that Exchange Online archiving is an additional cost to basic plans in Office 365.
An alternative approach to the additional cost of Exchange online archiving in Office 365 is moving the email in the archive boxes back into the primary mailbox if you have the space to do so. Then, the data can be moved to Office 365.
There is no supported option for a journaling mailbox in Office 365. If you still want to make use of this functionality, you need to use an on-premises Exchange server or look at a third-party journaling/archiving solution.
What about PST files? PST files can be the bane of the Exchange administrator’s existence. PST files are extremely challenging to work with, are easy to corrupt, and can be difficult to manage and even account for across an Exchange landscape.
Microsoft does have a free tool for Office 365 called the PST collection tool. You can use this in conjunction with the Office 365 Import Service to have a clear path to import PST file data into your Office 365 environment. Additionally, there are third-party tools available that allow scanning for PST files and importing them. Generally, third-party tools for managing PST file imports into Office 365 will provide more robust feature sets.
There is no question that the migration of on-premises resources to Office 365 is not without some complexity and challenges. If you have no one on your team that is experienced with migrating to Office 365, it may be a bit worrisome to attempt a migration on your own.
There are a number of very good third-party tools and services available that can assist with your migration project. What are some of these? You may want to check out the following third-party vendors of really great Office 365 migration tools:
Skykick dashboard (image courtesy of Skykick)
SkyKick provides automation for predictable, seamless Exchange to Office 365 cloud migrations. This includes the ability to move everything from basic email, calendar, and contacts to everything, including email signature blocks, rules, and calendar permissions.
Another great feature of SkyKick is the support of every Exchange version from Exchange 2003 forward, which will most likely cover most Exchange environments running today.
MigrationWiz dashboard (image courtesy of BitTitan)
BitTitan provides a tool called MigrationWiz for mailbox migrations. It can migrate individual components of a mailbox as well as all users and data. The MigrationWiz product has a long history of success with numerous clients who have been able to use the tool to migrate large numbers of mailboxes across to Office 365.
CodeTwo desktop app dashboard (image courtesy of CodeTwo)
CodeTwo is a desktop application that provides data migrations to Office 365 from Exchange Server, including Exchange 2003 and higher. Additionally, it supports servers running IMAP as well as migrating between Office 365 tenants.
Features include migrating email, calendars, contacts, calendars, tasks, etc. Also, Exchange Server public folders can be moved to Office 365 with the CodeTwo tools without any complicated processes or scripting.
Once you have migrated to Office 365, how do you facilitate the adoption of the applications and services your end-users will now have access to? Microsoft has a three-step plan to help with the adoption and success of your Office 365 migration found here.
The three steps for assisting with the adoption of Office 365 include:
- Drive Value
What is contained in each of these steps for promoting the adoption of Office 365 apps and services?
In the Envision phase, your business identifies the goals that you want to achieve in migrating to Office 365. This includes identifying the value gained by using the Office 365 environment. This can be the apps you will have access to, the improvement in processes and business flow, or other benefits from the Office 365 migration.
Also, in the Envision phase, you get together with key stakeholders and develop a rollout plan to identify the steps you will take to migrate your organization to Office 365. This leads to the next step in the process.
In the Onboard phase, your business will actually execute the rollout of Office 365. In this step, you will most likely want to begin with a test and small pilot group and then expand the rollout to include the rest of your organization.
The Drive Value step is an extremely important part of the process that allows you to expand the usage of Office 365 across your organization and help discover new Office 365 apps and services that your end users can take advantage of. After all, lasting cloud usage in Office 365 will be determined by the usage and satisfaction of your end-users.
Office 365 FastTrack (image courtesy of Microsoft)
Migrating to Office 365 provides many great features and capabilities to businesses today looking to stay competitive across various industries. There are a number of benefits to hosting core business elements such as email in Office 365. This includes shifting from large capital expenditures to a more palatable operational expense. It also allows having always up-to-date access to the latest versions of Exchange in the cloud.
Migrating core services can also free up IT staff from many of the mundane daily operational tasks that come with managing Exchange and other services on-premises and allows focusing on supporting applications that may be more directly related to the business at hand.
You must, however, consider the motivation behind migrating to the cloud very carefully and ensure it is the right move for your business. This is the key first step when considering a migration to the Office 365 cloud. After the decision to migrate to Office 365 has been made, a number of steps must be taken to ensure a successful rollout of Office 365 services.
These include identifying the best identity model for your organization, the best approach to the actual migration, how to handle archive mailboxes and PST files, and how to best drive adoption once the migration is complete. By carefully evaluating, planning, and executing your Office 365 migration plan, your business will have the best possible outcome and experience on the new Office 365 platform.