Given the growth of Microsoft Office 365, tenant-to-tenant (T2T) migrations were inevitable and have become more and more frequent. T2T migrations have essentially become the new Exchange and AD migrations we all know and love from the last 15 years.

That said, whilst the tenant migrations have become necessary, unless you are a born in the Cloud organisation, you will almost certainly also have some on-premises work to do as well. This will be in the Active Directory space for sure, and may involve migrating Users & Computers, Applications, GPOs and other resources.

The internal non-IT work is also not trivial so the whole project wrapper needs to be properly transitioned, change has to be managed effectively.  The Prosci ADKAR model has gained a lot of momentum in recent times and perhaps should be factored into the overall project.

So, whilst T2T is front and centre, it’s certainly not the end of the story for many organisations.

This blog is also available on BitTitan Bits & Bytes blog site as a feature….

Office 365 Tenant Migrations: Best Practices from Nero Blanco IT (Part 1)

Why?

So Why Are Organizations Migrating Between Tenants?

Well, nothing has changed much from pure business point of view right?  Businesses are still growing and acquiring / merging.  Some businesses are being broken up due to a divestiture, broken away or spun-off.  Perhaps regulatory requirements have enforced a split.

Here are a few of the main reasons we have seen:

• Mergers / Consolidation
• Acquisitions
• Divestures
• Spin-Offs
• Geography driven to meet data residency requirements
  • Although Microsoft do now offer multi-geo tenants.  Multi-Geo feature is available to customers with a minimum of 2,500 Office 365 subscriptions.
• Regulatory / Compliance
• Rebranding
• Rename of the Tenant
  • Again, Microsoft do have some support around this now and will consider it by special request
• Migrate form a Test/Dev to Production

Whatever the reason, tenant-to-tenant migrations require a considerable understanding of what you will and will not get from Microsoft in terms of assistance, 3rd party tools capabilities and of course IT Consulting Services from trusted professionals to bring this all together.  That’s where Nero Blanco comes in.  We can help transition you through the whole process whilst keeping your end users productive.

Migration Tools

Microsoft?

Well sort of….

You would think that with all these never-ending corporate mergers and takeovers in the business world that Microsoft would have a ready-made solution for consolidations of their own IT platform – especially a platform where they have been very strict about connected client versions, configurations and third party connectivity.

Exchange Online Cross-Tenant Mailbox Move Preview Program

In September last year (2018) we became aware of the: Exchange Online Cross-Tenant Mailbox Move Preview Program.

The Exchange Online Cross-Tenant Mailbox Move Preview Program is designed to validate new features in Exchange Online by having customers test migration scenarios using pre-release features in Exchange Online.  The program gives participants the opportunity to provide feedback to the Exchange product development team.

So not strictly designed as a tenant migration tool, more of a ‘test new features tool’.  It’s not available to everyone on General Availability and even so, it only concerns itself with Mailboxes, which is only one piece of the Office 365 puzzle – and quite frankly that is the low hanging fruit.  Exchange mailbox migrations are quite straight forward.  When you consider all that has to be done, you can quickly discount this as anything useful.

Now, we’re sure that with enough heavy hitters in this space Microsoft will perhaps relent and provide tooling for their biggest and best customers but given the rate of change in Office 365 and the roll out of new workloads to the service, it would require a lot of maintenance.  It took a long time for Microsoft to bring Exchange Migrations to the product via PowerShell New-MoveRequest.

And, is there really a good AD Migration tool from Microsoft?  ADMT anyone?

So, personally I’m guessing that a Microsoft inspired tenant-to-tenant tool may be a long time coming.  And as for Coexistence… well, more about that later.

3^rd Party Migration Tools

With a technology gap to fill, the free market always delivers.  A number of vendors have now inevitably provided a solution to the problem.

You need to decide what features and functionality are important to you, because we have seen that whilst many vendors are operating in this space, they all have their strong suits and their weaknesses.  Very few tools for example migrate SharePoint versions.  One vendor explained that the performance hit on the tool was too great and outweighed the genuine needs and request of customers.

MigrationWiz by BitTitan

We personally love MigrationWiz by BitTitan.  We’ve been doing migrations with BitTitan for some years now.  We like the simplicity of the interface.  It’s Cloud based so we don’t need to stand any kit up.  The migration throughput is second to none.  Their support is absolutely first class as is their documentation and knowledgebase articles.

Using Quality Consultants

However fast and reliable a migration toolset is, it is only one part of the puzzle.  The overarching steps to complete the migration requires a whole lot more.  Business buy-in, scheduling, planning, project management, transition management all has to be factored in.  Pretty much all players in the IT department will have some input.

If you are merging organisations there is for sure going to be some political hurdles that may slow your project down.  There will be timings for public announcements rebranding and pretty much all the usual soft skills required at the business and corporate governance levels.

This is where good consultants who know this process come in to play and can provide proper planning and understanding to the project for the key stakeholders and ultimately the end users.

Downtime

In all scenarios you must accept that there will be some downtime, however small.  Our advice: Accept a level of pain.  Hoping for a zero user-impact migration is just not possible.  Good consultants can minimise this with solid preparation and efficient cutover delivery.

Where a SMTP domain is being taken over (as part of a cutover migration) then there comes a time when you must stop the mail flow and cut-over the DNS records.  Even if your MX records are pointing to an appliance that can pause mail flow and hold incoming mail, it is still not reaching your end users.

In certain acquisition scenarios this may be moot of course, as the acquiring company may not care about the old branding, in which case the legacy tenant can have the forwarding enabled.

A merger / acquisition where the SMTP Domain name is being moved is going to be more complicated.  Re-creating any mail rules, DNS configurations for MX, DKIM, DMARC, SPF, Organisation sharing, will all take time and are directly affected by the tenant being available.

Further Reading:

• DomainKeys Identified Mail (DKIM)
• Domain-based Message Authentication, Reporting & Conformance (DMARC)
• Sender Protection Framework (SPF)

Removing all traces of a Domain name from the source tenant can take some time to complete as well as then re-populating objects in the target with the correct UPNs, Primary SMTP Addresses and proxyAddresses.

In a coexisted world, there may be no downtime for mail.  However, that is possibly the least of the worries in that scenario!  Those users still need to recreate the Outlook and OneDrive profiles.

Outlook and OneDrive

Users must re-create their Outlook and OneDrive profiles either on the workstations or mobile devices.  In some situation’s users may even have to be advised of their new username and password through an appropriate mechanism, hopefully in advance.

The amount of downtime or outages will be proportionate to the size of the organisation and the workloads, and particularly the type of migration.

Communication, Helpdesk and Documentation

Communicating in advance in clear details to your end users is crucial to stave off calls.

Ensuring the Helpdesk and Support Professionals are completely engaged and across the project is vitality important.  Documentation will inevitably need to be updated as soon as is practical.

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 Account sand 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 form booth 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

Other Policies

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 go cutover.

If you can’t go for a cutover migration, 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:

• 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 effectovley 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.

Summary

If an Office 365 tenant-to-tenant migration is on your horizon then good planning and defining your final goals are critical.

• Pick your workloads
• What is needed for compliance
• External Sharing
• Avoid Coexistence
• Pick the appropriate tool(s) and partner(s)

Getting the identity design is critical and should be established before undertaking ANY migration or coexistence steps.  Likewise, security requirements.  This should be agreed and nailed down before starting down the road of merging organisations.

Understand how MUCH data you have.  Huge amounts of data can take a long time to migrate.

Make sure all stakeholders understand what data and features are going to be available to each set of users.  E.g.  if the management team expects Yammer data to be migrated, then you will need to manage expectations and set goals before you get started.

You are going to have to rely on good planning, 3^rd party tools, manual tools and IT Consulting Services from trusted professionals, and that’s where Nero Blanco comes in.

Working Example

High Level Activities – Simple Divestiture Scenario

Here we are spinning off Fabrikam Limited from the parent Company (source tenant) “Contoso Holdings”.  Contoso Holdings is an agile start-up and was born in the Cloud.  They have no on-premises infrastructure.  Fabrikam will be going it alone and are only interested in migrating off Email and OneDrive data for users.

Prepare Target Tenant

• Create and configure tenant
  • fabrikamlimited.onmicrosoft.com created
• Primary domain(s) added to the target tenant
• Administration and Migration Service Accounts created appropriately
• Policy and Configuration Alignment, including
  • Maximum Message Size, Quotas
  • Disclaimers / Signatures
  • Retention / DLP Policies
  • Transport Rules

Prepare Identity

Use PowerShell script to create the following in the target tenant

• Users (licenced appropriately)
  • Some attributes may be crucial, like authentication mobile phone number
• External Contacts
• Shared Mailboxes
• Resource Mailboxes:  Rooms/Equipment
• Distribution Groups and Security Groups
  • We always recommend an email enabled security group hidden from the GAL for mailbox delegation Groups where we set Full Access and Send As (with mailbox auditing)

NOTE: some tools require running Request-SPOPersonalSite to create the destination OneDrive site.  MigrationWiz does this for you automatically

Prepare Migration Environment

• Ensure your migration service accounts have Global Admin Access, impersonation is enabled (if required), SharePoint Administrator maybe required in some instances
  • Some tools you may use an Azure App Service Account
• Buy MigrationWiz licences (the User Migration Bundle is a 12-month unlimited data per user licence!)
• Setup the MigrationWiz project
• Create your migration jobs (avoid using domains that you are going to move)
• Verify the Administration Credentials
• Deploy DeploymentPro to Workstations

“DeploymentPro configures Outlook email profiles to the new Destination server and moves users’ AutoComplete, email signatures, and PST files to the reconfigured email profile”

• Run the Pre-stage migrations
• Resolve Errors

Cutover Weekend: Source Tenant

• Pause inbound mail delivery (MX or 3^rd party)
• Ensure the default domain is NOT fabrikam.com
• Remove the fabrikam.com domain from all objects in Source
  • Cloud only objects, the tenant can do this for you up to 500 users
• Remove fabrikam.com from the tenant

               * This can take some time pending Office 365 processing of the above steps

Cutover Weekend: Target Tenant

• Verify fabrikam.com
• Set fabrikam.com to be the “Default Domain”
• Update all the target objects (email address, proxyAddresses and UPN)
• Resume inbound mail delivery (MX or 3^rd party)

Cutover Weekend: Final Pieces

• Run the final Sync in MigrationWiz
• Resolve any errors
• Reconfigure Phones and Tablets
• Run DeploymentPro for Outlook on Workstations
• Apply Retention/Litigation Hold if required
• Office
  • Users need to log out and back in
• OneDrive for Business
  • Users need to unlink their PC and then add OneDrive back in choosing the same folder
• Disable all end-user access to the source tenant

Lessons Learned

Lessons Learnt: Expectation Setting

• URLs change for SharePoint Teams, and OneDrive so previous embedded links won’t work (e.g. in emails or documentation)
• Team meeting URLs in Calendar meetings change
  • If the legacy tenant exists, users will in fact have their meetings over there!
• Users missing data?
  • Navigate back to the legacy tenant via the browser for OWA, SharePoint to the tenant that the user does not have configured on their workstation to access/check
• Devices not configured or failed to configure?
  • Use OWA until resolved
• Only take the minimum workloads and data required
• Expect a level of downtime during cutover
• Understand the Migration tools limitations and quirks and how to work around them
  • There will be an element of manual scripting and tweaking

Preparation

• Make sure you have access to make DNS changes BEFORE you remove the domain name from the source tenant!
  • Otherwise you can’t prove ownership of the tenant by adding the MX record.  Now your email is stranded
• Use a Licensed Global Administration account that does not have MFA or Conditional Access applied (for the duration of the migration) and is using a *.onmicosoft.com UPN
• Have enough target Office 365 licences (of the right type) – plus a buffer
• Not all migration tools take across SharePoint and OneDrive versions, nor design and workflow
• Beware you might need to make a Microsoft Service Request to relax some throttling settings
• OneDrive for Business quotas need to be same or higher in the target
• Don’t use the domain you are moving in any mapping files – use the *.onmicosoft.com alias
  • When you remove it, the migration tools won’t recognise the user in the target
• Don’t forget about mailbox delegation
• Don’t forget about mailbox Litigation Hold

Identity

• Beware of Source and Target Active Directory password complexity policies when performing a Directory Sync
  • Password complexity needs to be the same or lower for DirSync in the target
• Beware of AAD Connect custom attributes and mappings
• Beware of GAL name clashes for Merger/Acquisition projects
  • What to do for Groups (merge/rename)
  • Users – someone must give up their Primary SMTP Address and UPN
• Remove licences from the source to avoid ongoing charges!
• Understand how Guest Access works.  You may need to create Guest accounts

Keep It Simple and Sensible

• Avoid a staged / batched migration at all costs.  Coexistence is never easy/cheap
• Pre-stage Data
  • When pre-staging data bear in mind that most tools don’t do sync updates and deletions very well.  i.e. filing, mark read/unread, categorisation.  We recommend pre-staging something like:
    • email older than 30 days
    • ODfB/SP older than 90 days
• Have a list of Key Contacts for the client close to hand at time of cutover.  e.g. AD Admins, AAD Connect Admins, Network/DNS Admins, Office 365 Admins, IT Security Admins
• Remove end user access to the source tenant
  • As in actually de-license and block user
• Use BitTitan DeploymentPro and MigrationWiz
• Use Nero Blanco of course!! 🙂