Office 365 Tenant Migrations: Best Practices is a three-part series on Bits & Bytes featuring expert advice from Nero Blanco, an IT service provider in the UK specialising in end-to-end migrations. Read part one of this series here.
In parts two and three of this series, we covered important pre-migration considerations as an Office 365 tenant migration approaches. In the final installment, we summarize those steps and walk through a T2T scenario, applying those considerations to our plan and reviewing lessons learned.
If an Office 365 tenant-to-tenant migration is on your horizon then good planning and defining your final goals are critical.
- What is needed for compliance
- 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, 3rd 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
- Primary domain(s) added to the target tenant
- Administration and Migration Service Accounts created appropriately
- Policy and Configuration Alignment, including
- Maximum Message Size, Quotas
Use PowerShell script to create the following in the target tenant
- Users (licenced appropriately)
- Some attributes may be crucial, like authentication mobile phone number
- 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
Cutover Weekend: Source Tenant
- Pause inbound mail delivery (MX or 3rd 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
- Set fabrikam.com to be the “Default Domain”
- Update all the target objects (email address, proxyAddresses and UPN)
- Resume inbound mail delivery (MX or 3rd party)
Cutover Weekend: Final Pieces
- Run the final Sync in MigrationWiz
- Reconfigure Phones and Tablets
- Run DeploymentPro for Outlook on Workstations
- Apply Retention/Litigation Hold if required
- Users need to log out and back in
- 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
- 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!
- 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?
- 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
- 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
- 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
- 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:
- 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
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: