Migration Considerations

Key People

Sounds obvious, right? Have access to the DNS and Network Admins, the AD and AAD Connect Admins, the IT Security Team and so on. It’s amazing who you might need on the cutover event. In fact, as already stated, pretty much all of IT will be involved in some way, shape, or form.

Identity

Common Global Address List (GAL) – Getting the identity design right is critical and should be established before undertaking ANY migration or coexistence steps.  Almost certainly your organization will need a unified Global Address List.

Surfacing users as “Mail Contacts” in each tenant is relatively easy with PowerShell but what about Distribution Lists, Shared Mailboxes and Rooms/Resources.  Objects from each tenant should really be created as Mail-Enabled Users so that they can access resources and can be licensed to Mailboxes.  Having Guest accounts in Office 365 with a Contact of the same name is problematic.

Synchronising identities to a common platform should be the number one task.  In a merger/acquisition if both organisations are using On-Premise Active Directory and both running AAD Connect then all identity changes need to happen on-premises and flow to AD.  Directory sync needs to be AD to AD to surface each other’s objects.  On cutover, this needs careful planning as simply switching off current Sync and Federation tools (or descoping objects) could have a catastrophic impact as they might get deleted from the tenant they are syncing to.

Therefore, a robust and mature sync tool is a must.  Nero Blanco have written their own Directory Synchronization tool for this purpose called PowerSyncPro that has been designed from the ground up with tenant-to-tenant migrations in mind.

Guest Accounts and Mail Contacts – If the Exchange Mail Contact exists already, then you cannot create the Guest account, but you can vice versa.  This is because the Guest object is synced to Exchange Online (from MSOL /AAD) with proxyAddresses populated so after that you cannot use that proxy in any Exchange Online objects.  i.e. Contacts, Mail-Enabled Users, Mailboxes.  This is important because the migration tools will attempt to add permissions on initial and/or delta syncs.

In Office 365 when a Guest user is added to a resource, the Guest is sent an email invitation.  If you are pre-staging data then the timing of this is very important, because you may not want that invite going out 6 weeks before cut-over, because that target data is not “end user ready” yet.

Thus. the timing of creating Guests accounts that get added to Teams, SharePoint and OneDrive for Business is very important.

Security

Likewise, security requirements.  This should be agreed and nailed down before starting down the road of merging organisations.  Different organisations almost certainly will have had differing security requirements for corporate data protection.  New Identity sign-on sophistication may be required for privileged user accounts and enabling Multi-Factor Authentication and compliance requirements for users and devices.  Conditional Access will probably be on for Admins, and even enabled org wide on one or the other tenant.

Note: You cannot migrate EMS Intune policies and Azure Information Protection (AIP) configuration.  Nor DLP and Exchange Transport Rules.  These all need to be re-created with collaboration and agreement from both organisations.

Sharing Policies

Configuring sharing policies in Office 365 whilst not quite a dark art, is definitely something that needs planning and documenting.  Sharing can be configured at these levels:

• Azure AD – External collaboration settings
• Exchange Online
• SharePoint
• Sharing outside your organization / Who can share outside your organization
• Default link type / Default link permission
• Additional settings
• Notifications
• OneDrive for Business
• Teams – External Access and Guest Access

Also consider other policies such as Compliance Polices, Data loss prevention (DLP), Messaging records management (MRM) and In-Place Hold and Litigation Hold, Advanced Threat Protection (ATP), Intune EMS, Azure Information Protection.

Interim Coexistence

Avoid this if at all possible – it is not easy or straight forward. Always try to go cutover. And if a cutover migration isn’t an option, then…

Coexistence for Enterprise Customers: Sometimes it just will not be possible to perform a cutover migration because the user base is simply too large.  Therefore, interim coexistence may be required.  Cross Tenant Organisational Sharing and Routing can be set-up relatively easily where Domain names are not being shared, but when you need to have a common Domain name it’s a lot more difficult.

There are a few 3^rd party vendors out there offering a coexistence solution of sorts, but it is mainly: routing, Free-Busy and DirSync you will be getting.  The routing and Free Busy concepts still relay on Target Routing Domains being set either as targetAddresses on Mail-Enabled Users and Contacts, or SMTP Forwarders on Mailboxes (but the presence of a mailbox will break Free Busy).  External emails will have to be processed first by an appliance such as Mimecast etc that can do recipient based routing re-writes, and likewise outbound routing re-writes, as the primary SMTP address for a user may not actually be the common Domain name.

Understanding the limitations affecting workloads is crucial to ensure end user impact is minimalised.  Particularly your end users being trained and understanding which account to log on with where when they are accessing a shared resource like SharePoint, Teams or OneDrive files.

Reasons to avoid coexistence and things to consider:

• The Primary Domain name can only be attached to one tenant at a time
• A choice has to be made will that be the Source or Target
• Mail Routing to primary domain name
• Per above, needs a 3^rd party appliance
• Free Busy
• 3^rd Party Free Busy broker service
• Requires a well thought out use of targetAddress and AvailabilityAddressSpace (but won’t work when the Mailbox exists in the source)
• Mailbox delegation between migrated and non-migrated users does not work
• Ongoing GAL synchronisation
• Tooling that can cope with on-going steady state AD to AD synchronisation
• Source to Target Migrated objects in the Cloud require on-premises AD attribute changes
• Teams
• Users will have to contend with Organisation Switching, and will effectively be a Guest to some materials at one point or another.

User Confusion

• Which UPN logon to use for migrated users accessing back to non-migrated data
• Different Password – how / where to change
• Which UPN logon to use for non-migrated users accessing migrated data types
• Different Password – how / where to change
• Guest Accounts

Data Discovery and Workloads

A key consideration in deciding to do a tenant-to-tenant migration is identifying what data your organization actually needs to move AND how MUCH data you have.  Huge amounts of data can take a long time to migrate.  Don’t forget, this is all content migrating over WANs – “Cloud to Cloud”.

Initially people think of a tenant migration as just moving email and documents from SharePoint and OneDrive, but actually Office 365 and Azure AD is complete platform in its own right.  It is by now deeply integrated into your IT infrastructure and processes.

Plus, not ALL workloads can actually be migrated, i.e. Yammer.  So make sure all stakeholders understand what data and features are going to be available to each set of users.

So, before you start a tenant migration, spend some time figuring out what data you have in Office 365, and if you can migrate it or not.  At the bare minimum you need to know the SMTP domain names that are cutting over and the full list of users and objects migrating.  Not forgetting there may be a mix of On-Premises and Cloud only objects.

• Make sure that you take a FULL EXPORT of the source objects including all attributes. This will need to be run from on-premises and Cloud
• Beware of username and group name conflicts

Then things like:

• Any special routing topologies and Rules, Connectors, DLP, Federation, Message Hygiene
• Mail-Enabled Users, User Mailboxes, Shared Mailboxes, Room and Equipment, Distribution Groups, Mail-Enabled Security Groups, External Mail Contacts
• Mailbox Delegation Exports
• SendAs, Send on Behalf Of, and Full Access
• Litigation Hold
• Export this and ready to re-apply
• SharePoint Sites and Teams
• OneDrive for Business Personal Sites
• OneDrive for Business Quotas

You need to know all this so that you can re-create it all in the target in advance so that the migration tools have an endpoint to deposit data.

So is it just email, SharePoint and OneDrive?

Nope, not anymore. Consider all these things:

Licensing, Payment Methods, Identity, OneDrive for Business, Teams, SharePoint, Dynamics, Azure, SMTP Domain names, DNS Changes, ADFS, Message Hygiene, Disclaimers, Signatures, Transport Rules, Federation, DKIM, DMARC, SPF, Data Leakage Protection, Azure Information Protection, Mail Routing with Partners, Compliance, RBAC, AAD Connect, Shared Mailboxes, Litigation/Legal Hold, Retention Policies, Rooms & Resources, Active Directory Sync, Distribution Groups, External Mail Contacts, Guest Access, MDM/MAM, Enterprise Mobility & Security, Windows 10 Licensing, Intune Compliance, Deskless Workers, Staff Hub, Planner, Sway, Advanced Threat Protection, Backups, Mobile Devices, Office ProPlus, Yammer, Sharing Policies, Conditional Access, MFA, Global Administration, Role Based Administration, Hybrid Exchange and Coexistence, Public Folders, SMTP Relays Skype for Business, VoIP, Calling Plans, Education, Not for Profit, Geo Restrictions, Network and Latency, ADFS, ExpressRoute, Monitoring, PowerBI, SSPR, Reporting…

Devices

Never forget that it is not just Microsoft Windows AD Domain joined machines consuming your data.  Today’s users probably have at least 2 devices (sometimes even more than four!) with Phones, Tablets, Desktops, Laptops and home PCs in the mix.

Reconfiguring devices is often not trivial for basic users.  New policies may be applied creating unexpected and unwanted results.

Active Directory

Although the focus here is tenant-to-tenant migrations, unless you are a born in the Cloud organisation, chances are that you have some underlying Active Directory to deal with too.  At some point you are going to need to migrate Users and Computers and Applications and maybe even decommission one of the ADs.