On-Prem Exchange to Office 365: Why Bandwidth, Not the Tool, Sets Your Timeline

The tool you pick for an on-prem Exchange migration matters less than the bandwidth on the source side. Whether you run BitTitan or SkyKick, the upload pipe out of the Exchange environment is what decides how long the move takes. That is why the single most useful thing you can do is prepare weeks in advance. These third-party tools let you run a prestage migration, pulling over the bulk of the data before you ever touch the MX records, so cutover becomes a short, low-drama step rather than a marathon.

This is a high-level overview of the migration steps using BitTitan. For the complete step-by-step guide with screenshots, follow this playbook PDF (opens in new tab). The guide is specific to BitTitan, but the same concepts apply with any tool.

Stand up the destination tenant#

• Provision a net-new tenant in Office 365. It is provisioned with the .onmicrosoft.com domain. Purchase it directly or under the CSP model through a distributor.
• Add and verify the domain. In the 365 Admin Center, go to Setup > Domains > Add Domains, then add the domain and verify with a TXT record.
• Add users and apply licenses one at a time, by bulk upload via PowerShell, by bulk upload via CSV, or through AD Connect setup (opens in new tab).

To bulk import users with passwords:

Import-Csv -Path 'FilePath' | foreach {New-MsolUser -UserPrincipalName $_.UserPrincipalName -FirstName $_.FirstName -LastName $_.LastName -DisplayName $_.DisplayName -Password $_.Password -ForceChangePassword $False}

Prepare the source Exchange environment#

This is where the bandwidth planning happens. Spend your time here.

• Set impersonation rights for the admin user. Open the Exchange shell on the Exchange server and run:

New-ManagementRoleAssignment -Role ApplicationImpersonation -User <admin_user_name>

• Disable the throttling policy on Exchange. Refer to the KB article (opens in new tab) for your particular environment. This is only relevant for Exchange 2010 and later. Exchange 2007 and earlier do not have throttling policies.
• Audit upload speeds. Bandwidth is often limited in Exchange environments. Auditing upload speeds gives you a better idea of how long the migration will take.
• Upgrade software on workstations. If applicable, install the latest Office 365 software on all user workstations.

Set up a BitTitan account#

• Create a login (opens in new tab) for a BitTitan username and password.
• Create a customer by entering the primary domain name and customer name.

Push the Outlook reconfiguration agent#

BitTitan includes a tool called Deployment Pro that reconfigures Outlook profiles after the migration. You can push it out through GPO or by email.

• Decide on GPO or email delivery. GPO instructions (opens in new tab) or email instructions (opens in new tab).
• Track users with the agent installed. Devices register and match a user's email address to a computer in a one-to-one relationship. Each computer reports a "heartbeat."

Prepare the migration endpoints and tune concurrency#

• Set up source and destination endpoints in the BitTitan portal. Find the source endpoint under "Exchange Server 2003+." The destination is Office 365. Provide admin credentials.
• Autodiscover users. Clean up the user list as needed and remediate UPN issues by clicking the pencil icon next to a user.
• Verify credentials. This tells you whether there are errors. The most typical errors are insufficient impersonation rights or wrong admin credentials. A successful check shows "Completed Verification."
• Subscribe users. Select all users, click the last icon on the top toolbar (three lines), and choose "Apply User Migration Bundle." It takes 3 to 5 minutes to propagate.
• Determine the maximum number of concurrent migrations. If you attempt too many concurrent migrations, the server times out and all threads fail. The guideline is three per 1 Mbps of bandwidth. In the BitTitan portal, go to Edit Project > Advanced Settings > set the maximum number of concurrent migrations. Audit to find the sweet spot once you kick off the migration.

Prestage, then plan the MX cutover#

• Run a prestage pass bringing mail from the Exchange server to Office 365. This brings over the bulk of the data before MX cutover. Set it prior to 60 days. Any user whose status changes to "Failed" is almost 100% due to a server timeout; adjust your maximum number of concurrent migrations and rerun those users.

• Define the MX cutover time to 365. Preferably during non-business hours. Go to 365 Admin Center > Setup > Domains to find the MX record you will need to change. The format follows: Domain-com.mail.protection.outlook.com. Take note of any third-party connectors for email filtering such as Symantec or Barracuda. Look up the steps for creating connectors in 365; these providers usually have step-by-step guides you can find easily.

Full pass and MX cutover#

• Run a full pass to bring over the remaining mail, calendars, contacts, notes, and rules. This should not take long as long as the prestage pass completed. Once the full pass completes, run up to 10 delta passes to collect residual mail.
• Switch the MX records. Point the records at 365. Do not green-light this step if there is still a lot of data to move over. Test inbound and outbound mail flow.

Post-migration cleanup#

• Confirm the DMA agent ran successfully. DMA status goes into "Completed" after successful authentication by the end user. Any user who fails authentication three times goes into an "error" status. Reschedule those users and make sure they have the correct 365 password.

• Hand out mobile reconfiguration guides. Mobile users can set up their mailbox on their phone with these guides: iPhone (opens in new tab) and Android (opens in new tab).