Partner Guidance

Hosted Mail Migration to Office 365 Guidance to hosted mail partners enabling migration of their installed base to Office 365

(Exchange Online)

v1.1 | 2016-05-04 | Page 2 of 14

The information contained in this document represents the current view of Microsoft Corporation on the issues

discussed as of the date of the publication. Because Microsoft must respond to changing market conditions, it should

not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of

any information presented. This document is for informational purposes only.

MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS

DOCUMENT©2016

Microsoft Corporation. All rights reserved.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under

copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or

transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any

purpose, without the express written permission of Microsoft Corporation.

Microsoft Corporation may have patents or pending patent applications, trademarks, copyrights or other intellectual

property rights covering subject matter in this document. The furnishing of this document does not provide the

reader any license to the patents, trademarks, copyright or other intellectual property rights except as expressly

provided in any written license agreement from Microsoft Corporation.

Microsoft, Active Directory, ActiveSync, Outlook, SharePoint, SQL Server, Windows, Windows Live, Windows Mobile,

Windows Server, and Windows Vista are trademarks of the Microsoft group of companies.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

v1.1 | 2016-05-04 | Page 3 of 14

Table of Contents Background and context ............................................................................................................................... 4

Migration scenarios ...................................................................................................................................... 4

Partner pre-requisites and constraints ......................................................................................................... 5

End-to-end process ....................................................................................................................................... 7

Customer and mailbox migration ................................................................................................................. 8

1. Preparation ........................................................................................................................................... 9

One-time changes ................................................................................................................................. 9

Client considerations ............................................................................................................................ 9

Tenant verification and mail re-routing .............................................................................................. 10

Other per-tenant settings ................................................................................................................... 10

Large tenants ...................................................................................................................................... 10

2. Directory synchronization ................................................................................................................... 11

3. Mailbox data migration ....................................................................................................................... 11

4. Cutover ................................................................................................................................................ 12

5. DNS updates ........................................................................................................................................ 13

6. Clean up and completion .................................................................................................................... 13

Networking requirements and throughput estimates................................................................................ 13

Identity ........................................................................................................................................................ 14

v1.1 | 2016-05-04 | Page 4 of 14

Background and context This guidance document is intended for Microsoft partners/hosters1 that are planning the migration of

their installed base of existing customers to Office 365 under the Cloud Solution Provider (CSP) 2

program. Such partners will typically have their customers hosted in an on-premises environment and

wish to migrate that customer data to the Office 365 cloud such that the partners can then continue

their administration and management in Office 365. This guidance assumes that the on-premises,

hosted environment that makes up the source platform/s is based on Microsoft server technology

(Exchange Server). While guidance covering migration from other non-Microsoft and/or proprietary

platforms is an eventual goal, the current version of this document does not include such migration

scenarios.

This guidance focuses explicitly on moving hosted mail platforms to Exchange Online. Migrating to

other Office 365 workloads such as SharePoint Online or Skype for Business is currently out of scope.

This guide is also not a step-by-step set of instructions, as each deployment’s needs will vary, but

describes, at a high level, the steps required, highlights important considerations and deployment

pitfalls, and outlines support constraints and boundaries.

Migration scenarios The following distinct migration scenarios where the source (partner) platform is a multi-tenant, hosted

Exchange mail platform are typically in view. Note that all the scenarios listed below are not covered in

this guidance document and when necessary are identified as such:

Full move to Office 365

o In this scenario, the hoster is planning to move their entire set of customers to Office

365 and do not intend to maintain any future on-premises directory services (Active

Directory).

o At the end of such a migration, all customer data will reside in Microsoft data centers

and customers’ users’ identities will be exclusively homed in Azure Active Directory

(AAD)3.

Mail-only move to Office 365. Hoster plans to continue to offer on-premises or online apps to

their customers.

o The hoster plans to move only their customers’ users’ mailboxes to Exchange Online in

Office 365. Customers’ users will authenticate through AAD for access to Exchange

Online however will also maintain an on-premises set of credentials in order to

authenticate to their on-premises or other online apps.

o Note that identity federation of the manner where the partner is the identity provider

and all authentication requests are routed to the partner’s security token service (STS) is

explicitly not supported by Microsoft in the multi-tenant, hosted model that this

guidance document covers.

1 The terms ‘partner’ and ‘hoster’ are used interchangeably throughout this document. 2 For additional information on the CSP program, please visit https://partnercenter.microsoft.com/partner/programs. 3 “Azure Active Directory is a comprehensive identity and access management cloud solution that provides a robust set of capabilities to manage users and groups. It helps secure access to on-premises and cloud applications, including Microsoft online services like Office 365 and many non-Microsoft SaaS applications.”

v1.1 | 2016-05-04 | Page 5 of 14

o This scenario is not covered in detail in this document however some guidance is

provided in the Identity section.

Dependent on 3rd party panel provider

o Many hosters use 3rd party panels to aggregate and manage their offerings in an online

marketplace and to integrate into the hoster’s operational and business backend

systems. The 3rd party panel is typically responsible for managing the hoster’s customer,

order, provisioning and fulfillment lifecycles.

o While the guidance provided in this document can clearly be utilized by hosters that

have leveraged 3rd party panels, no specific treatment is provided for any variations

introduced by this scenario.

Hybrid

o The option for a hoster to manage their customers in a hybrid on-premises and cloud

model is not supported.

Partner pre-requisites and constraints An assumption of this document is that partners receiving the guidance here are already familiar with

the CSP program. In addition to the standard CSP requirements of managing customers’ billing,

providing customer support, managing primary customer communication, etc., there are some criteria

that are specifically relevant to migration to Office 365 that must be satisfied.

Installed base of mail-enabled customers

o The partner must have an existing installed base of non-Office 365 mail-enabled

customers. This implies partners must have an existing, typically on-premises, hosted

mail platform that provides e-mail (and potentially other related) functionality to their

customers.

o This guidance is only useful in the case that the partner is planning on migrating this

installed base to Office 365.

Partner is fully onboarded to CSP

o The partner should have been fully onboarded to CSP from nomination through signup,

credit check, enrollment and final contractual agreement with access to the CSP Partner

Center having been granted. Onboarding to CSP allows the partner to resell Microsoft

(Office 365, Azure, etc.) services and administer and support those customers through a

variety of Microsoft-provided tools and API-based integration.

o The partner need not already be transacting i.e. re-selling Microsoft services through

CSP.

Familiarity with and usage of CSP tools

o The partner must be familiar with the various tools made available through CSP. In

particular, the Partner Center, workload-specific Admin Centers (e.g. Office 365 Admin

v1.1 | 2016-05-04 | Page 6 of 14

Center, Exchange Admin Center, etc.) and the Partner Center SDK4, CREST5 and/or

GRAPH6 APIs, if being utilized, should be well-understood.

Offer (SKU) definition

o The list of available offers or SKUs (Stock Keeping Units) in CSP is provided through the

Partner Center. The partner must have selected the CSP offers they wish to use for the

customers being migrated.

o It is very important that partners evaluate each offer carefully. Office 365 offers have

been carefully curated with specific target customer archetypes in mind. Partners need

to therefore ensure that the offers selected for the customers being migrated make

sense for those customer profiles including feature sets, license number limits, etc.

One AAD tenant per customer

o In AAD, the cloud directory services that undergird Office 365, each customer entity

must be associated with one and only one customer tenant. For hosters migrating their

customers from an on-premises, hosted model, this implies that each Organizational

Unit (OU) in a hoster’s on-premises Active Directory translates to a single customer

tenant in AAD.

Customer DNS management

o Each customer tenant must have at least one domain associated with it. Each customer

tenant created in AAD minimally requires a default sub-domain of the form

<tenantname>.onmicrosoft.com e.g. contoso.onmicrosoft.com. This could of course be

used as the default domain for the customer but it is more likely that the customer has

or wishes to use a custom domain of the form <tenantname.com> e.g. contoso.com.

o The partner is responsible for all customer engagement related to DNS management of

custom domain/s the customer has and wishes to use. This may involve working with

the customer to create specific DNS records to verify domain ownership, configure

AutoDiscover, establish mail routing, etc.

Exchange Server versions

o The processes described in this document assume that the source hosted Exchange

environment is running Exchange Server 2010 (/hosting mode and a standard

installation), 2013 or 2016 and that the environment was configured in compliance with

the Exchange Server Hosting Guidance documentation. This migration guidance does

not cover older versions of Exchange.

o Many hosters have bought or built a control panel/provisioning solution, and the steps

described in this document do not account for any such solution and constraints it might

have. It is critical for hosters to work with their control panel vendor or development

team to fully understand the effect of moving mailboxes between on-premises and the

cloud and any billing, provisioning or other workflows that might be impacted as a

result.

Public folder support

4 The Partner Center SDK “makes it easy for Microsoft Cloud Solution Provider partners to integrate their sales systems with the Microsoft Partner Center system which powers the Cloud Solution Provider (CSP) program.” 5 The CREST or Commerce REST API is used “to create customer accounts, manage customer profiles in the Microsoft Commerce Platform, and purchase and manage orders and subscriptions of Microsoft products for their customers.” 6 “The Azure Active Directory (AD) Graph API is an OData 3.0 compliant service that you can use to read and modify objects such as users, groups, and contacts in a tenant.” A hoster can use GRAPH to manage their customers’ tenants, users, etc.

v1.1 | 2016-05-04 | Page 7 of 14

o There is no built-in method or tool to allow migration of parts of a public folder

hierarchy to a single Office 365 customer tenant. If this is required the hoster will need

to use export/import of data, a 3rd party migration toolset, or develop an appropriate

tool and process.

Data cleanliness

o Depending on the state of the hoster’s current platform, ensuring data cleanliness may

be required. For a positive Office 365 experience for the customer, the hoster should

validate that data being migrated into Office 365 is accurate and complete prior to

initiating the migration process.

Resourcing

o Finally, the partner should plan for appropriate availability of resources including project

management, PowerShell development, RESTful development (if integrating using the

Partner Center SDK, CREST and/or GRAPH APIs), test, etc. competencies.

End-to-end process The high-level process a hoster could go through would minimally include the below phases. Depending

on their individual organizational processes, a hoster may choose to expand on or further flesh out this

overview process.

Figure 1: End-to-end migration process

CSP readiness

o CSP onboarding

The partner must be onboarded onto CSP prior to starting the migration of their

hosted Exchange customers to Office 365. This means the partner has gone

through nomination, invitation, credit check, enrollment and contract

agreement and should have been granted access to the Microsoft Partner

Center.

o Transacting in CSP

While it has been noted above that the partner is not required to already be

transacting through CSP i.e. re-selling Microsoft services in CSP, it is highly

recommended that the partner actually do so. By transacting in CSP using CSP

tools or APIs, the partner becomes familiar with providing customer support in

the CSP model, selling Microsoft services through CSP, using CSP tools and other

practices, patterns and processes that will be utilized with their migrated

customers as well.

Customer engagement

o It is critical that the partner engage each customer prior to initiating their migration.

This is required because the partner will need to make decisions on the customer’s

behalf such as what the customer’s .onmicrosoft.com subdomain should be, what

custom domains need to be configured (domain ownership verified, relevant DNS

records created/updated, etc.), what offers (SKUs) the customer will be purchasing and

CSP readinessCustomer

engagementCustomer and

mailbox migrationClose out

v1.1 | 2016-05-04 | Page 8 of 14

migrating to and so on. At the end of this stage, the hoster should have documented

and prepared customer-specific elements that will need to be managed not only

through the migration/move process but also after the customer is homed in Office 365.

o The partner will also need to manage customer expectations in terms of planned

migration outages, customer support, etc.

o It is also important to note that in moving from hosted Exchange to CSP, there are

contractual changes for the customer. In CSP, the customer needs to also agree to

Microsoft terms and conditions (in addition to other terms that may be required by the

hoster). Additional changes impacting feature differences, price differences, etc. might

also drive delays while the customer evaluates and agrees to the change/s.

Customer and mailbox migration

o This phase is detailed further in the following section titled ‘Customer and mailbox

migration.’ It covers the execution of the migration, guidance and best practices to

follow.

Close out

o After all customer moves have been completed the hoster may choose to completely

deprecate and de-install their on-premises hosted environment. Any engineering,

marketing and product closure and cancelation activities would be completed in this

phase.

Customer and mailbox migration The migration of tenants from an on-premises Exchange multi-tenant deployment to Exchange Online is

a multi-step process. The most important aspect of this process is to understand that at the highest

level this is essentially a series of cutover migrations – every single tenant, except for the very last

tenant (more on this later in the document), must be active either fully in the hoster’s on-premises

deployment or the Office 365 tenant. In other words, it is not supported at any time to have active

users from any one customer tenant spread between the hoster’s Exchange system and Office 365.

Failure to comply with this constraint will possibly result in refusal of support assistance but may also

likely result in data loss, tenant isolation issues and other serious problems. Hosters should not put their

customers’ data at risk by attempting to use Exchange Hybrid with a multi-tenant system!

Figure 2: Customer and mailbox migration process

The first step in migration, Preparation, involves creating the customer tenants in Office 365, validating

any custom domains the tenant uses, identifying any configuration objects that need migrating and so

on.

The next step, Directory synchronization, is when the objects in the tenant in the on-premises

deployment are synchronized with the tenant in the cloud.

The next step, Mailbox data migration, is the part where the bulk of email in the tenant mailboxes is

moved to Office 365.

1. Preparation2. Directory

synchronization3. Mailbox data

migration4. Cutover 5. DNS updates

6. Clean up and completion

v1.1 | 2016-05-04 | Page 9 of 14

The next step, Cutover, is the part where the mailboxes are brought fully up-to-date and then users

begin connecting to Office 365 for the first time. At this point the customer has started using Office 365

and stopped using their on-premises environment.

The next step, DNS updates, is the part where DNS is updated so mail delivery and client AutoDiscover

services are updated to point directly at Office 365.

The final step, Clean up and completion, is the part of the process where Directory sync is removed,

objects are deleted from the on-premises Exchange installation and any final configuration steps taken.

The following sections describe these processes in more detail. The information provided is intended to

help guide a hoster through the process of building their own migration workflow and not to provide

step-by-step details on which commands to run and when.

1. Preparation There are several steps to prepare for a migration of tenants to Office 365. Some of these steps are

performed only once, and apply to all the moves a hoster may make, and some must be performed for

each tenant being moved.

One-time changes In the hoster’s own Exchange on-premises deployment the MRS Proxy should be enabled and accessible

from the Internet. There must be a certificate from a publicly-trusted CA installed. This change needs to

be made just once and enables moves to Office 365 for all of the hoster’s customer tenants.

Client considerations Before moving any tenant, it is very important to know the clients that the users in that tenant are using

so the hoster can plan for communicating client configuration changes that might be needed.

In particular, it needs to be understood that the current version of Outlook and Office 365 only supports

Outlook 2010 and newer for client connectivity. If users in the tenant being moved are using a version

of Office older than that they will not be able to connect to their mailboxes following the move. The

hoster can use the Exmon tool (available here) to determine the versions of the Outlook client being

used.

In most cases Outlook will detect the mailbox move and follow the Autodiscover redirection process and

get reconnected to the mailbox, but the hoster should be prepared for some cases where this might not

happen. This is often as a result of clients running out-of-date software or if distributed

autodiscover.xml files have been deployed for manual profile configuration, so ensuring the tenant’s

users have updated Outlook and understanding the impact of local XML files prior to the move is

recommended.

The hoster should also determine if the tenant’s users are using any mobile devices and make sure they

understand that they will need to either update their device profile or re-create them following a move

to Office 365.

If the tenant has POP3/IMAP4 clients in use, they will need to re-configure their clients following the

move unless the hoster leverages some kind of smart POP/IMAP/SMTP proxy.

v1.1 | 2016-05-04 | Page 10 of 14

Additionally, if the tenant’s users are using Outlook Web App (OWA) they will need to be communicated

the OWA URL they will use following the move (unless this is accomplished in DNS) as there will be no

automatic redirection to the cloud as Exchange Hybrid is not being used.

Tenant verification and mail re-routing Prior to initiating any mail migration, the hoster must create the customer’s tenant in AAD using the CSP

Partner Center or an integration they may have developed using CSP APIs (Partner Center SDK). Once

the relevant customer tenant is created in AAD, the hoster must also purchase relevant subscriptions for

the customer, create users and assign subscription licenses to those users appropriately.

The customer’s tenant should be provisioned and any custom domains verified. Custom domain

verification will require a TXT record to be put into any custom DNS zones to be used with the tenant.

The customer tenant created in Office 365 will have a unique <tenantname>.onmicrosoft.com

subdomain assigned to it. This mail routing domain for the tenant should be added as an Accepted

Domain in the hoster’s on-premises Exchange deployment and the domain added to the Email Address

Policy associated to the tenant (or stamped on the tenant mailboxes using the hoster’s provisioning

tool). Later this address will be set as the target address for the MailUser objects left behind on-

premises – this is the address used in subsequent Autodiscover redirections which helps the Outlook

client discover the new mailbox location as well as for redirecting mail that comes in for the user post-

move, but before the MX record is re-pointed.

The hoster will also need to configure mail routing between their on-premises server and Office 365 to

allow mail to route from the hoster to Office 365 before the MX records are switched. The Microsoft

TechNet article, “Set up connectors to route mail between Office 365 and your own email servers” has

details that will help accomplish this task.

Other per-tenant settings It is important to check if the customer tenant being moved has any custom transport rules, journal

rules, custom address lists, Manager/Delegate or Mailbox Delegation access etc. The hoster will need to

re-create those in the tenant after directory synchronization has taken place. Permissions set within the

mailbox generally will migrate without issue, permissions set in the local AD will not be migrated.

Large tenants The move process described in this document is a cutover move – the hoster must move each tenant as

an atomic unit. This can be hard with large tenants or smaller tenants with vast amounts of data as the

online mailbox moves can last for weeks. The hoster can therefore consider the following options:

Have the customer reduce the amount of data they have in their mailboxes. They can export

data to PSTs and re-import following their moves, or simply age-out old content.

Use PST export coupled with the Office 365 Import Service7 to reduce the data in the users’

mailboxes to an amount that can be moved online through the Import Service’s “Network

upload” feature. The Office 365 Import Service also supports a “Drive shipping” method

whereby data files can be copied to an encrypted hard drive which is physically shipped to

7 At the time of publishing this document, the Office 365 Import Service is not enabled for use in an admin-on-behalf-of model. This capability is expected in the coming months.

v1.1 | 2016-05-04 | Page 11 of 14

Microsoft, where data center personnel upload the data to a temporary storage area. The

hoster can then import the data to the relevant mailboxes.

If there is only one large customer tenant to be migrated, the hoster can use Exchange Hybrid to

allow the tenant to co-exist in both the on-premises Exchange system and Office 365 but only if

this tenant is left to the very end of the migration, and only if no other tenants exist on the on-

premises Exchange system.

o Once all the other tenants have been migrated to Office 365 and only a single tenant is

left there is then no need for on-premises Address Book Policies and so on-premises

Exchange deployment can be treated as a single tenant, standard Exchange system. The

Hybrid Configuration Wizard can be run and the migration of that last tenant can be

then accomplished over a period of weeks or months.

o If several large tenants need to be moved however this approach won’t work and the

hoster will need to consider the strategies mentioned previously.

2. Directory synchronization Unless the hoster chooses to issue new usernames and passwords to a customer tenant’s users

following the migration of the tenant, a directory synchronization from the on-premises system into the

new tenant created for the customer being moved will need to be performed. This will synchronize the

objects in the on-premises tenant with the new customer tenant in Office 365.

Microsoft recommends the hoster use Azure Active Directory Connect to perform this synchronization.

Azure AD Connect will also allow the hoster to synchronize users’ passwords to the cloud, so the user

can continue to use the same credentials (username and password) to access their mailbox following the

migration. If the User Principal Name (UPN) of the user in the hoster’s on-premises directory is equal to

their vanity/custom domain SMTP address, and that custom domain has been added to Office 365, they

will be able to use the same username and password as they did prior to the move.

Azure AD Connect allows the hoster to filter the objects desired to be sync’ed based upon the

Organizational Unit (OU) they existed in on-premises or a Security Group. It is typical in a multi-tenant

configuration to have objects from each tenant separated in this fashion so the tool makes picking the

objects the hoster needs to sync very simple.

Only one instance of Azure AD Connect may be installed on a single server and so the hoster needs to

consider how to manage the synchronization of many tenants at the same time. If the hoster chooses to

use a more complex metadirectory synchronization tool to allow multiple management agents to exist

at the same time on the same machine, they must ensure any published support guidelines for using

such a tool against Office 365 are followed carefully.

Once the tenant’s directory objects are synchronized into their Office 365 tenant, and any other

configuration objects they need (transport rules, journal rules, etc. that were itemized during the

Preparation phase) have been created, moving of the mailbox data can begin.

3. Mailbox data migration To move mailbox data (and any associated archives) from the hoster’s on-premises Exchange system to

Office 365, multiple cutover migrations using Mailbox Replication Service (MRS) based mailbox moves

will generally be performed.

v1.1 | 2016-05-04 | Page 12 of 14

Moves using MRS allow users to keep the same Outlook profile following the move. If that is not

important, for example the customer tenant being moved does not use Outlook, one could consider

doing a cutover migration using Outlook Anywhere (though these are limited in size). This process is

described here and offers another way to get mailboxes for smaller tenants into Office 365. Remember,

if it is important that customers’ users maintain the same Outlook profile, MRS-based moves need to be

performed, if it is not, Outlook Anywhere-based moves are the preferred method.

In either case, note that having any one tenant split between on-premises and the cloud unless it is the

last tenant being moved, is not supported.

Batches of users to move are created by first running the New-MigrationEndpoint cmdlet in the tenant

pointing at the hosted Exchange system and then using the New-MigrationBatch and New-MoveRequest

cmdlets to perform the mailbox move requests. The CompleteAfter or SuspendWhenReadyToComplete

parameters should be used to ensure the cutover timing can be controlled. If multiple batches for one

tenant are created, ensure that they complete as close as possible to the same time to prevent splitting

a tenant between the hosted deployment and the cloud.

There are several parameters available to use when using the cmdlets and these will need to be

evaluated to plan for things such as message size limits, what to do with bad and large items, and how

to ensure the correct target address is set on the objects left behind in the on-premises directory.

As indicated earlier, there is no integrated process or tool to allow migration of parts of a public folder

hierarchy to a single Office 365 tenant. If migrating parts of the Public Folder hierarchy and content to

each tenant is required the hoster will need to use export/import of data, a 3rd party migration toolset,

or develop an appropriate tool and process.

The number of concurrent moves and other migration related parameters can be adjusted using the Set-

MigrationEndpoint and Set-MigrationBatch cmdlets.

4. Cutover Once the batch(es) for the tenant being moving are at the CompletionInProgress stage, that specific

tenant is ready to be cut over.

The effect of this change must have been communicated to end-users, and the hoster’s helpdesk team

needs to be ready to receive calls and help customers with any reconfiguration. Additionally, the

cutover time window should have been previously agreed to with the customer. Ideally cutovers will be

completed during a period of low customer activity.

When all of this is in place the Complete-MigrationBatch cmdlet may be used to complete the batch(es).

When a migration batch is finalized, the cmdlet does the following for each mailbox in the migration

batch – it runs a final incremental synchronization and converts the source mailbox to a mail-enabled

user in the source domain.

When the finalization process is complete, the batch can be removed by using the Remove-

MigrationBatch cmdlet. If a migration batch has a status of Completed with Errors, the Complete-

MigrationBatch cmdlet may be re-run. The cmdlet will attempt to finalize the failed users.

At this stage some tests should be run for the customer, ensuring for example that Outlook can

reconnect to the new mailboxes, ensuring mail is delivered to the mailbox correctly (note that at this

v1.1 | 2016-05-04 | Page 13 of 14

stage incoming mail will be delivered first to the on-premises deployment and then re-delivered to the

target address specified on the target object).

Outlook desktop clients: clients which are fully patched and up-to-date should connect successfully.

The client may receive a pop-up asking users to restart Outlook, and once that is done and if everything

has been configured correctly, the client should then connect.

POP/IMAP: these clients will need manual re-configuration. Server settings for the client can be

obtained from here.

Exchange Activesync: these clients will need to have their server name changed (assuming the users’

logon names and passwords have not changed), or new profiles can be created.

Outlook Web App: OWA users should be able to log in using the Office 365 OWA URL.

Once all users are working, the mailbox migration process is complete.

5. DNS updates Once all mailboxes have been moved and users are able to successfully connect to their mailboxes, the

customer’s AutoDiscover A/CNAME/SRV records and MX records should be updated to point directly to

Office 365. This process takes the hoster out of the client connectivity/mail delivery process which

simplifies troubleshooting and makes the client discovery and mail delivery optimal. It is also possible

that if MX records are not re-routed and a large amount of mail is routed to Office 365 that those IP

addresses will be throttled leading to a subpar experience. The last step of DNS updates is therefore

very important.

6. Clean up and completion Now that mailboxes have been moved and clients are directly connected to Office 365 all that needs to

be ensured is that all clients are able to connect without any issues and all data, groups and other

objects or configuration have been migrated.

Depending upon the strategy that has been chosen for ongoing directory synchronization, the AAD

Connect instance that was used to synchronize the tenant’s directory to Office 365 may no longer be

needed and could be removed. Note that PowerShell needs to be used to remove the Directory Sync

settings for that tenant.

Once that is done the tenant configuration from the hoster’s on-premises environment can be removed.

Networking requirements and throughput estimates Microsoft has published documentation offering guidance and advice on planning for the network

requirements of Office 365. The online document, “Network planning and performance tuning for Office

365” (available here) is a good starting point to understand the network considerations.

The “Office 365 migration performance and best practices” online article (available here) discusses

factors affecting mailbox migration. In the Performance for migration methods section of the

document, the Hybrid migration entry is relevant for the migration method described in this document.

v1.1 | 2016-05-04 | Page 14 of 14

Identity The process described in this document results in an account being created in AAD, with it becoming the

security principal associated with the Exchange Online mailbox. This has several consequences

depending upon the hoster’s infrastructure and other services. This section is provided to highlight

those issues.

When the user logs on to their mailbox they will be using the account created in AAD. Note this is a

cloud identity, not federated with any on-premises AD. It is not supported to use federated identities

from a hosters AD containing many users from different tenants.

If the hoster has no other reason to maintain an account for the user once the mailbox is moved, they

can remove the AAD Connection and allow the account to remain in AAD only. However, if the hoster

also delivers apps from their own datacenter with their own on-premises AD, requiring that the user log

on to their AD to get access to their apps they then need to maintain an identity for the user on-

premises.

In this case they might need to maintain an AAD Connect connection from their AD to the customer’s

tenant so if the user changes their password in AD the two passwords will stay in sync. However, this

presents an issue if the user changes their password in Office 365, i.e. in AAD, as there is no reverse

password sync capability for AAD Connect and the two passwords will get out of sync. The only

mitigation against this issue is to tell the customer they must change their passwords against the

hoster’s AD, and have that password change synchronized to AAD via the AAD Connect connection, or to

capture it using something such as the Password Change Notification Service (PCNS) and then set that

same password on the cloud account.

It might also be that the two passwords being out of sync is not an issue, in which case the user simply

needs to understand they now have two sets of credentials, one for the hoster’s apps and one for Office

365 and other Microsoft online services.

End of document