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: 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
• 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

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 licenses 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. 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. 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

About Nero Blanco IT

Highly skilled and experienced independent contractors formed Nero Blanco, when we saw an opportunity to change the way large technology migration and consolidation programmes are delivered. We wanted to help organisations with mixed IT environments to make a seamless transition to the latest technology.

For us, no two projects are the same. We take a new perspective for every project we work on. Our solutions are tailored to fit your challenges, whilst keeping in mind cost, efficiency and maintaining a highly personal level of support. We relish the challenge of making your migration as smooth and painless as possible. Our goal is the timely delivery of an end-to-end technology solution that will dramatically improve your performance results.

Our expert team can help companies like yours to easily migrate from the old to the new and we hold the following accreditations: