How To Migrate From Exchange 2010 To Office 365?

I would like to discuss on “How to Migrate from Exchange 2010 to Office 365?”. We will be going through the straight cut over process. This will entail setup of the Microsoft Tenant, mirroring the settings across, changing of DNS records and lastly data migration. Let us look further into some of the steps and what to look out for.

Creating a Microsoft Tenant. The tenant names will always append the Onmicrosoft.com. Therefore, you decide on a business name <Name>.Onmicrosoft.com. Even if you are just testing, rather implement the correct name. Then be sure if you are testing, ensure that you always keep the Admin account details safe and create another failsafe account. During the “Testing” phase of a client, they generally end up adding their own domain. Should you need to move the domain to another tenant you will have to log on and remove the domain before adding it to another tenant. This will avoid logging calls with Microsoft to assist which can potentially delay your timelines if you on strict deadlines.

Once you Tenant is configured with the actual domain, you should set your primary domain to “Internal Relay”. This means during the provisioning of any services, if emails from any organization on Office 365 emails you and a distribution list or mailbox does not exist yet, it will route it out. For you set a domain to “Internal Relay” on Office 365, it will request that you have a send connector. Setup the send connector pointing to your current MX Records. Once configured, you are now ready to mirror your environment across to Office 365.

You configure the mailboxes with aliases, distribution list and add the members, configure Resource mailboxes and external contacts. Once all is setup, now comes the main requirements during a migration, the “DATA Migration”. This is done before we cut over DNS Records and setup all the users. A lot of people attempt to migrate the data, the old fashion method. Export to PST and then import into the newly created profiles. Firstly, if you have over 100 of users, your internet lines need to be able to handle this. Secondly, importing a PST will entail the legacy X500 addresses. This may course issues when replying to an old email internally.

I would recommend using 3rd party application which will help migrate the data across from the source (Where you are moving from) to destination (Office 365) without having to  upload individually. Once all the data have been migrated, you set a time it which you would like to cut over. Then Change the DNS records. These records entail the MX Records, SPF and CName.

 

Once you setup the users on Office 365, I would suggest adding a forwarder on each mailbox to the users alias address User@domain.onmicrosoft.com without leaving a copy in the mailbox. The forwarders will keep the mail flow from one platform to another. Most 3rd Party applications will complete the data migration. Once the data migration is completed, you can then decommission the source (where you migrate from)

Generally, there are 3 types of Migration to date:

  1. Straight Cut Over Migration
  2. Hybrid Deployment
  3. Migration by PST

Straight Cut Over Migration

This method entails you connecting Office 365 into your current environment and then migrating the mailboxes from Exchange to Office 365. Assuming you have Exchange 2010,this should be fairly simple process, however ensuring you are SP3. When it comes to the RU version, that can be debateable. Some may say you must be on the latest, but we all know bugs are always there.

Some important aspects if you are connecting Exchange 2010 to Office 365 are Outlook Anywhere. By default, it should be enabled and confirmed with SSL if your users are connecting externally. Certificate, you can use a self-signed but always good to have a 3rd party certificate matching your domain.

A dedicated Migration Account is always recommended. We have seen in the past where by Admin uses the Admin account and should the account be compromised, there is a major problem. Create a dedicated Migration Account and assign the required permissions.

Ensure you setup your primary domain on the tenant and validate it. Thereafter, setup a migration endpoint to your Exchange 2010 environment. Run Batch Mailbox Migration, verify users and data has been migrated, assign the licenses and lastly, move the DNS record pointing to Office365. This is just a highlighted overview on this process. There are more steps involved.

Hybrid Deployment

This type of migration is basically getting the best of both worlds. On-Premise and in the cloud experience. This method is generally used by large organization because of the staging method and large data to be moved. This process with entail setting ADFS and Web Proxy to authenticate.

Have both On-premise and Exchange Online, users will be able to connect better depending if they are in the Office on off site. This setup require complexity and also for corporates, it is more secured.

Migration by PST

This method is the native method which is most commonly use in the Small to Medium Enterprise Businesses. There is work involved with Exporting the Data, Setup and configure the Office 365 tenant and then importing the data into Exchange Online. There are three methods to importing the data.

Importing data into Exchange Online:

  1. Office 365 Import Services
  2. You can ship the data on a disk to Microsoft. (Chargeable by Microsoft)
  3. Setup the Outlook profile and import the PST using Outlook

You setup the tenant and configure it, switch the DNS to point to Office 365 and import the data. This is a simple method.

Here are some 3rd Party Applications which I would recommend:

Bit titan

Kernel Migrator for Exchange

CodeTwo Exchange Migration

Email Migration Software

Stellar Data Recovery

Be the first to comment

Leave a Reply

Your email address will not be published.


*


This site uses Akismet to reduce spam. Learn how your comment data is processed.