There are several built-in migration types for Office 365: Cutover, Staged, Remote and IMAP. For older Exchange Servers, Staged and Cutover are your only choices. IMAP is usually reserved for your on-premises non-Exchange servers or for a move from a hosted provider. I covered a cutover migration in my last article and in this article I will cover some Tips and Tricks for a Staged Migration.
Staged Migration – Why?
When talking to my clients, one of the first decisions is to determine the migration type as it helps drive the rest of the design discussions. Cutovers are quick with no need for coexistence. This works well for smaller environments or ones with very little data to move. However, as an environment gets bigger, the need for something more long-term emerges. For large environments with Exchange 2010 and later, a remote move will be used. However, if the move is from Exchange 2003 or 2007 and coexistence is desired, a Staged Migration is your path for Office 365. Remember, Staged Migrations are not intended for organizations that would like to maintain on-premises and cloud mailboxes in a ‘hybrid’ environment.
Staged Migration
Stages migrations are one of two choices organizations have for a migration from Exchange 2003/2007 to Office 365. Staged migrations usually require more time and effort for planning, preparation and execution. This could include DirSync and/or ADFS, load-balancer or WNLB configuration and a long-term schedule. Scheduling on users to be migrated should be done early in the migration process as it will help mitigate any issues that may occur with this approach.
Tips
Active Directory
Often overlooked until something doesn’t work, your Active Directory health can and will affect your migration to the cloud. If you don’t have a good understanding of Active Directory, find someone who is. Whether that’s Microsoft with their ADRAP program or an experienced consultant, make sure someone reviews your environment to make sure it’s healthy. I’ve posted some of the issues I’ve seem in Hybrid and Cutover migrations, but the same issues (or other issues) could affect your Staged Migration.
ADFS (with DirSync) vs just DirSync
One of the more important decision points has to do with how your enterprise will be connected to Office 365. Will you work with just DirSync (with Password Sync) or do you want full Single Sign on and have chosen to put in ADFS. Before deciding this, make sure to read articles like this for deciding on your end-user experience:
SSO – DirSync vs ADFS
ADFS Pros and Cons
In some cases ADFS will be the solution chosen simply because it provides a more seamless experience to the end-user. There will be some that choose just DirSync for its simplicity and lower cost.
How to Decide?
Deciding factors
- Cost and Budget for the solution
- Management’s requirements
- Desired End User experience
From a purely management/cost perspective, DirSync is a great solution. One server for Office connectivity, no complicated high availability and very little loss in functionality.
If you must have everything and a great user experience, then ADFS is the way to go with you Office 365 migration.
Time Frame
As much as I like to make migrations go as fast as possible, there are cases where this isn’t either physically possible or possible for the business to handle. Plan the migration schedule carefully. Make sure all of your pieces are in place before beginning. If there are multiple sites, take into consideration things like updating software remotely, on site or offsite/remote support, volume of users to move, speed of internet links, etc. These factors will determine how many weekends will be required to move the entire company to Office 365.
A case in point for this would be a multi-state bank that wants to concentrate IT on each Branch Office. In this model, each office would potentially be given weekend for their migration along with IT staff to support any user issues that may occur with the migration. Doing do would reduce the potential for the Help Desk to be overwhelmed by too many support calls the day after migration. This method would also allow a higher level attention to be paid to managers and anyone requiring ‘white-glove’ service levels.
Certificates and Outlook Anywhere
One of the often overlooked parts of a migration to Office 365 is the validity of certificates as well as the configuration of Outlook Anywhere. On several occasions I’ve come across expired certificates, invalid certificates (wrong names possibly), self-signed certificate or no certificate at all. Certificate issues should be resolved before attempting any Office 365 migration. Make sure to use a certificate that is verifiable by a third-party CA like Entrust, GoDaddy, or Digicert.
Outlook Profiles
Just like the Cutover migration, your Outlook users will need to create new Outlook profiles to connect to their new mailbox in Office 365. Unlike a Hybrid deployment for Exchange 2010 or 2013, the Staged migration copies the mailbox to the cloud. Thus the need to create a new profile.
DNS Updates
Don’t forget to update your DNS records once all mailboxes are moved to the cloud. This includes AutoDiscover and mail flow. If possible, use the Office 365 interface to make the changes. This eliminates human mistakes while making the changes. Also, lowering TTLs on each record that needs to be changed will reduce the amount of time it takes for a client to connect to the new services.
Teams and Shared Mailboxes
Shared mailboxes are mailboxes that a groups of users have access to. When it moved to the cloud, anyone associated with the mailbox should be moved as well. This is different from a cutover migration as every mailbox is moved at once. Not doing so for a Staged migration will result in pop-ups and access issues. The same goes with users that share managers. Please see my article on Team Calendars for what can happen when a manager and those that report to him are not moved at the same time.
Final Thoughts
What else can you do to make the migration go smoothly?
- Planning and Testing.
That’s it. Make sure that you mitigate as many issues as possible before migrating production users. If this delays you migration, the let it be delayed. I would rather deliver a project 1 week late and have the migration go very smooth then deliver a project on time and have massive issues.
Further Reading
How To Perform a Stages Migration
Choosing a sign-in method
