Office 365 Migration Considerations (Part 2)

If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the first part in this article series please go to Office 365 Migration Considerations (Part 1).

This article continues my interview on Office 365 migration considerations with Kelsey Epps, a Technical Consultant with Concepps Group and a Microsoft MVP for Office365 who runs a blog called the Office 365 Technical Support Blog.

Mitch: Thanks for the clear and detailed outline of the migration process. How would this differ if you were to stage a migration to Office 365 for a company that has 200 employees, starting with a 15 user trial? Could the company have accounts both on-premises and in the cloud? Let’s say the company currently has POP3 mail via their Internet provider. How would the migration to Office 365 differ from what you described previously?

Kelsey: Since this is a larger migration from a POP3 provider, there is advanced planning and configuration that needs to happen. With 10 users we can flip the switch and reconfigure the desktops with very little to no impact to the business. When we are talking 200 accounts, to migrate with minimal impact, isn’t that easy; but it can be done. The way to achieve this is to have both systems active at the same time. This leaves us in a co-existence scenario with the current POP3 provider. I have completed a migration for another company where we used the following plan.

1. Overview, Discovery and Planning session with the client — In this meeting, we discuss Office 365 and I give them a tour of the services and show them single sign on with my own lab account. They share details with of their current setup and their end state goals. For the purposes of this question, let’s assume they are going to migrate all 200 accounts to Office 365 on an Enterprise E3 plan, with single sign-on.
2. Trail Tenant — I setup the client trail tenant account on Office 365 and let them discover and play with Office 365.
3. Migration Plan — I take all the notes that I made in the planning session and I come up with a detailed migration plan. Once the plan is completed and signed off by the client, I will begin the setup and migration process.

Since we are in a co-existence scenario with a POP3 provider, mail routing is going to be an issue when we have two services running. This means that we need a way to route email from a user that is still on the POP3 service to a user that is on the Office 365 platform. The reverse is true as well. For this we need to create a vanity domain within Office 365 and forward email from the POP3 provider to the vanity domain. Exchange Online (Office 365) allows for a Shared domain, which means that if the user is not present in Exchange online, then it will forward out. I have created a workflow in Figure 1 that shows the email flow.

Production Email Domain Name – @contoso.com

Vanity Email Domain Name – @mail.contoso.com

Figure 1: Workflow for migration from POP3 to Office 365.

4. Add and verify the domain and vanity domain to the Office 365 account — This includes DNS records for the production email domain name and the vanity email domain name. All records can be added with the exception of the MX record. This should point at the POP3 provider until the migration is completed.
5. Complete the Exchange Online setup (Distribution lists, external contacts, delegate permissions, meeting rooms, etc…)
6. Clean up Active Directory – This makes sense for so many reasons, but the most for Directory Sync. We can filter the OUs that we want to sync to Office 365. Checkout this BLOG post on how to do that.
7. Setup ADFS and ADFS Proxy Servers.
8. Setup Directory Synchronization.
9. Test single sign on.
10. Migrate the Pilot Group to Office 365
    • Add an alias, for the vanity domain, to the local AD account and for a Synchronization with Office 365
    • License the user accounts in Office 365
    • Update the client desktop with Office and Office 365 Desktop Applications
    • Setup email alias and email forwarding on the POP3 provider
    • Setup Outlook Profile
    • Import existing email from PST file, into Office 365
    • Test email flow to other Office 365 Users
11. Migrate the rest of the accounts following the same process as the pilot group. This can be done over time with a proper migration plan.
12. Update MX record to point at Office 365.
13. Remove vanity domain from Office 365.

The end result of this plan allows for a staged migration to Office 365 with users on both systems. The only user impact during the migration is when we have to update the client desktop with Office and Office 365 Desktop Applications. The complete migration should be transparent to your customers and partners sending you email.

The complete implementation plan is on my BLOG, starting with this post – Advanced Email Migration to Office 365 from a POP3 Service Provider — Part 1.

Mitch: What if the company currently has Microsoft Exchange deployed on-premises as their messaging solution? Will it be easier or more difficult for them to migrate to Office 365? How would it differ from what you just described for migration from POP3?

Kelsey: That is a good question. There is still a lot of configuration work to be completed, but this time there isn’t any advanced email routing that we need to rely on. I would say that the effort is the same, but the steps are completely different. I am usually called in to setup and pilot the migration. Once the process is in place and the pilot group is moved to Office 365, the local IT staff will take over and complete the migration. To migrate Exchange, we have three different choices; Cutover Migration, Staged Migration and Hybrid Deployment.

Cutover Migration — “Use E-mail Migration in the Exchange Control Panel to migrate all the mailboxes and corresponding mailbox data from Microsoft Exchange to your cloud-based e-mail organization. This type of migration is called a cutover migration because all on-premises mailboxes are migrated in preparation for moving your entire e-mail organization to the cloud.” This method can only be used for Exchange 2003 and Exchange 2007 and the organization has fewer than 1000 mailboxes. I like to refer to this one as flipping the switch migration. Once you configure the Exchange batch job, it will sync everything into Office 365. Once the data is in the cloud, you flip the MX record and start using Office 365

Staged Migration — “You can use the E-mail Migration dashboard in the Exchange Control Panel to migrate a subset of your on-premises mailboxes to the cloud. This process is called a staged Exchange migration. It allows you to move some mailboxes to the cloud while maintaining the rest of the mailboxes in your organization’s on-premises Exchange environment.” This is very similar to the Cutover migration, but you are breaking the migration down into manageable groups of people. This method can only be used for Exchange 2003 and Exchange 2007 and the organization has fewer than 1000 mailboxes. This requires some email routing between the two systems (on premise and Office 365), but it’s not that complicated to setup. The drawback to this method is that you will lose the ability to have rich co-existence (free/busy and calendar sharing), a single OWA, message tracking and MailTips; between the two systems, during the migration process.

Hybrid Deployment — This is a method where you introduce an Exchange 2013 or 2010 hybrid server into your on-premise Exchange organization. The role of this server will be to act as an Exchange Federation gateway between on-premise and Office 365. This allows you to move accounts to and from the cloud with no disruption to the user. There is very little impact to the user, other than setting up the desktop with the new version Office. All the data that is stored on the Exchange server is moved. The drawback to this method is cost.

Let’s assume, for this question, they are Exchange 2007 on-premise and wanting to migrate all 200 accounts to Office 365 (Enterprise E3 accounts) using the Hybrid Deployment. The end goal is that the customer wants to use single sign-on and have no Exchange accounts on-premise.

1. Overview, Discovery and Planning session with the client — In this meeting, we discuss Office 365 and I give them a tour of the services and show them single sign on with my own lab account. They share details of their current setup and their end state goals. For the purposes of this question, let’s assume they are going to migrate all 200 accounts to Office 365 on an Enterprise E3 plan, with single sign-on.
2. Trail Tenant — I setup the client trail tenant account on Office 365 and let them discover and play with Office 365.
3. Migration Plan — I take all the notes that I made in the planning session and I come up with a detailed migration plan. If you need help with a migration plan, make use of the Microsoft Exchange Server Deployment Assistant. This is a tool that Microsoft introduced to help with Exchange deployments. You are prompted to enter some information on current state and the desired end state. Microsoft will create a migration plan for you within minutes. I generally include some of that content into my own migration document. Once the plan is completed and signed off by the client, I will begin the setup and migration process. Keep in mind that you will need third party verified SSL certificate for ADFS and Exchange. I will either use a wildcard SSL certificate or a 5 name UCC SSL certificate. With the 5 name UCC certificate, I will include all the Exchange names (mail, Autodiscover, servername) and the ADFS name (sts).

Figure 2: Workflow diagram from the Microsoft Exchange Server Deployment Assistant.

4. Add and verify the domain to the Office 365 account — This includes DNS. All records can be added with the exception of the MX and Autodiscover records. We want those to be pointed at the on-premise servers until the migration is completed.
5. Clean up Active Directory – This makes sense for so many reasons, but the most for Directory Sync. We can filter the OUs that we want to sync to Office 365. Checkout this BLOG post on how to do that.
6. Add the Exchange 2013/2010 Hybrid Server — This is a fairly straight forward process and is completely detailed in the document you get from the Exchange Deployment Assistant.
7. Setup ADFS and ADFS Proxy Servers.
8. Setup Directory Synchronization with rich co-existence enabled.
9. Complete Exchange Federation with Office 365 — This process is completely detailed in the document you get from the Exchange Deployment Assistant.
10. Migrate the Pilot Group to Office 365
    • License the user accounts in Office 365
    • Move the user mailbox from on-premise to Office 365
    • Update the client desktop with Office and Office 365 Desktop Applications
    • Setup Outlook Profile
    • Sign into Lync
11. Migrate the rest of the accounts following the same process as the pilot group. This can be done over time with a proper migration plan. Since we are in rich co-existence with Office 365, there is no loss of features.
12. Migrate from Exchange Public Folders to Microsoft Office 365.
13. Update MX and Autodiscover records to point at Office 365.

At this point all the users should be in Office 365 and you can remove the Exchange from your local domain.

Be sure to check out my BLOG. I am in the process of writing a complete series, Getting to know the NEW Office 365. In this series of posts, I detail setting up Office 365, various methods of migrating to Office 365, single sign-on deployment and administering Office 365.

(to be concluded in the final article in this series)

If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the first part in this article series please go to Office 365 Migration Considerations (Part 1).