As O365 migrations grow rapidly, tenant to tenant migrations will become more common. There are many reasons why companies would consider a tenant to tenant migration, including, when a company decides to sell part of a company, or buys out another company or migrates from a test/dev to production environment. In such cases, there may be a requirement to migrate part of O365 services such as Exchange Online Mailboxes, OneDrive, SharePoint and Teams from one tenant to another. Whatever the reason, tenant to tenant migrations require some serious planning, because when performing a tenant to tenant migration a number of features are not migrated and you need to be prepared for this, communication is key, and there will always be some downtime involved.
So now we know a few of the reasons why a tenant to tenant migration would be considered, we would firstly look at Microsoft to provide us with a service to migrate O365 services from one tenant to another, right? It makes sense, as both tenants are managed by Microsoft. Microsoft must have a cloud service which provides a tenant to tenant migration. That’s what you’re thinking, but unfortunately, Microsoft do not offer a cloud service which can migrate O365 services from one tenant to another. There was an announcement made at Microsoft Ignite that it was something Microsoft were working on, so fingers crossed.
Because Microsoft don’t offer such a service, we need to look at third party services, and there are a few of them. I have personally, worked with the migration service provided by BitTitan (MigrationWiz). The Bit Titan cloud service allows tenant to tenant migrations for Exchange Online (Mailboxes), OneDrive, Teams and SharePoint and their interface is easy to get around. But I wouldn’t recommend BitTitan (MigrationWiz) for Share Point migrations. I use a company called ShareGate for tenant to tenant Share Point migrations, it’s a much better service and less effort required when the data from source to destination comes across. Feel free to research into the different third party services out there.
Let’s move on and look at popular types of Tenant to Tenant Migrations
1) A company moving from a source tenant to a new tenant, utilising a new domain. (Tenant to Tenant Migration using a different domain)
2) A company moving from a source tenant to a new tenant, utilising the same domain. (Tenant to Tenant Migration with the same domain)
Lets take a look at both, starting with point 1
Tenant to Tenant Migration using a different domain
In this scenario, a company may have sold part of it’s company to a different company. The buyer already has a domain and would like to migrate users into their own tenant and utilise an existing domain already in use at the destination tenant. For example, company 1 (company1.com), sells part of it’s company to Company (company2.com). Users migrated from Company 1, will utilise the domain name of Company 2 (company2.com) for O365 services. A forwarder would be setup for each mailbox from source tenant domain to mailboxes located in destination (MigrationWiz creates the forwarders for you), but when the user replies from destination, they would reply from a different domain registered at the destination tenant. Some of used this type of migration when wanting to migrate an existing domain from source to destination to allow them to migrate users in batches and allow for less risk, but it may not look professional when the users at the destination reply to customers from a different domain. A complete cutover of mailboxes, remove domain from source tenant and add to destination tenant can sometimes be the best option.
Tenant to Tenant Migration with the same domain
In this scenario, a company sells part of it’s company and there is a requirement to utilise the same domain at both source and destination tenant. The same domain can not be registered at two locations (Tenants) at the same time so downtime will be required when you cut over (Weekend cut over recommended). Here a big bang approach is usually carried out and all mailboxes are cut over at the same time.
Is downtime required? Will there be an impact to users?
In both scenarios there will be some downtime and a large number of calls to the helpdesk if users are not kept up to date (Communication is key). If you’re looking for zero impact in a tenant to tenant migration, you’re not going to get that no matter how hard you try. There will always be some issues and a little downtime. For example, there will be some downtime when you remove the domain from source tenant, add it to new tenant and reconfigure MX records.
Communication is key
It’s important that you keep your users informed to reduce the number of calls to the helpdesk. Get your documentation ready, as there will be a requirement for users to recreate their Outlook profile, unless you use MigrationWiz service DeploymentPro which assists with auto recreating the profile, migrates signatures from old profile, auto complete details and even PST files are migrated from old to new Outlook profile.
OneDrive profiles will also need to be recreated, so it’s important that you have all documentation prepared before the project.
It’s also important communicating with the team or individual who has access the domain name portal, AD admins, O365 and Network Admins. Ensure everyone is aware and ready to assist when requested. Keep them all updated and involved in your project plan. One of your team members may know something you don’t and help with reducing impact at the time of migration.
MIgrationWiz provide well detailed procedures for both tenant to tenant migrations using a different domain and tenant to tenant migrations using the same domain so it’s worth taking a look if you decide to utilise MigrationWiz.
What data to capture?
It’s important that you capture all the required data before starting the migration. For example, mailbox permissions, calendar permissions, O365 Groups, mail contacts, send as permission and a lot more is not migrated as part of a tenant to tenant migration, so you will need to create these again.
Capture the below data, so that you have a record that you can look at when a user reports issues and you can recreate it in the target in advance so that MigrationWiz has an endpoint to deposit data.
– A complete user list from source AD (all user details including smtp, email aliases, UPN, username, first name/surname, username etc). A full export.
– User Mailboxes, Shared Mailboxes, Room and Equipment, Distribution Groups, Mail-Enabled Security Groups, External Mail Contacts
– User calendar permissions
– O365 groups & included Members
– O365 distribution Groups & included Members
– O365 mail-enabled Security Groups & included Members
– O365 shared mailboxes & included members
– Mailbox permissions
– Mailbox Delegation Exports (SendAs, Send on Behalf Of, and Full Access)
– Mailbox stats
– Mail user contacts
– MFA Status
– Litigation Hold (export, and ready to reapply)
– SharePoint Sites and Teams
– OneDrive for Business Personal Sites
– OneDrive for Business Quotas
I personally use BitTitan for the migration of mailboxes/one drive and ShareGate for SharePoint. ShareGate will require for you to spin up some servers, as this is not an entirely cloud service, whereas MigrationWiz by BitTitan is.
What issues do I need to be aware of (Lessons learned)
Below are the lessons learned I have documented with previous migrations:
1) URLs change for SharePoint Teams, and OneDrive so previous embedded links won’t work (e.g. in emails or documentation)
2) Team meeting URLs in Calendar meetings change (If the legacy tenant exists, users will have their meetings over there!)
3) If users are unable to access Outlook client, use OWA in the meantime as a backup
4) There will be downtime when you remove the domain from source tenant and add to destination. Plan this well
5) Make sure you have access to DNS, so you can add txt records to verify domain and amend MX records
6) You will require a global admin account at source tenant and destination tenant. This is required to create source and
destination end points on the MigrationWiz portal (Global account needs to use a onmicrosoft.com account at both ends)
7) Have enough O365 licenses at target tenant
8) Not all migration tools take across SharePoint and OneDrive meta data and versions. You will lose this info
9) OneDrive for Business quotas need to be same, or higher in the target tenant
10) Don’t use the domain you are migrating in any mapping files. Make sure you use the .onmicrosoft.com alias.
If you were to use a non .onmicrosoft.com alias, the migration tools won’t recognise the user in the target when you remove the domain from source tenant
11) Mailbox delegation permissions don’t migrate so ensure you have these details
12) Mailbox litigation hold don’t migrate
13) Mailbox full permissions don’t migrate
14) Mailbox Send As don’t migrate
15) Password complexity needs to be the same or lower in the target
16) Beware of AAD Connect custom attributes and mappings
17) After the migration, remove licences from the source else you’ll continue to be charged
18) You may need to create guest accounts
19) Most recommend to avoid a staged/batched migration as coexistence is never easy or cheap. A cutover/big bang is sometimes the best option. Discuss this with your team
20) Always pre stage data using MigrationWiz or your tool of choice
21) Migrationwiz is a copying tool and not a syncing tool, if you copy data using MigrationWiz, and a user decides
to clean up their mailbox, those changes are not replicated to destination tenant. When the user is migrated, all that email will reappear
22) Pre Stage emails older then 60 days and then come down to 30 days, and lower as you come closer to the cutover weekend
23) If you have a lot of data, you could migrate the latest 30 days of email, migrate and let the remaining emails trickle in as
the users continue to use their mailboxes
24) ODfB/SP stage data older than 90 days
25) DeploymentPro provided by BitTitan (MigrationWiz) is a good tool to auto reconfigure user profiles. It can be configured to execute after the cutover. An agent needs to be deployed (DMA – Device Management Agent) to each machine. This can be pushed out via group policy or even sent via email to the user if they have the permissions to install.
26) Don’t rush, sit down with your team and plan the process
27) If you’re migrating to a new tenant and a new infrastructure, such as a new deployment of Mimecast, AD, internet proxy etc, you could migrate a domain from source tenant which is not in use, to allow you to pilot, and ensure all your new services function (Mimecast, Proxy, etc). This will allow you to prove the concept, migrate across some test users, test email flow, filtering, proxy etc before migrating across the live domain.
28) Use a different provider such as ShareGate for migrating SharePoint data My personal opinion
29) A pilot test is recommended so you can have a feel of what features don’t come across and how you will resolve those issues
Here is a high level list of what you need to do. In this example, a migration is taking place utilising the same domain and a new tenant (Cut over migration)
Prepare Your Target Tenant
- Create and configure tenant (*.onmicrosoft.com)
- Create administration and migration service accounts
- Use Powershell scripts to create users (licence users appropriately)
- Create/configure authentication mobile phone numbers, external contacts, shared mailboxes, resource mailboxes (Rooms/Equipment), distribution and security groups
Prepare Your Source
- Ensure your migration service accounts have Global Admin rights (For example MigrationWiz requires a global admin account configure source and destination endpoints)
- Buy MigrationWiz and SHareGate (SharePoint) licences, if you’re using MigrationWiz, or purchase licenses for the migration tools you are using
- Setup a MigrationWiz project
- Create your migration jobs (avoid using domains that you are going to move and instead use the .onmicrosoft.com account)
- Deploy DeploymentPro (DMA agent) to workstations (Automatically configures Outlook profiles and migrates user AutoComplete, Email Signatures, and their PST files to the new Outlook profile)
- Run pre-stage migrations and resolve errors
Migration Weekend:
- Remove the domain to be migrated to your new tenant all objects in your source tenant. If you don’t do this, you won’t be able to remove the domain from the tenant
- When the domain has been removed from all objects at the source, remove from the source tenant. This can take some time. At times it’s been neccessary to contact Microsoft if the new domain does not register on the destination tenant
- On the target tenant, add and verify the domain you removed from source tenant
- Set the domain as the default domain
- Update all the target objects such as email address, proxyAddresses and UPN
- Reconfigure MX records
- Run the final syncwithin the MigrationWiz portal
- Reconfigure phones, ipads etc and run DeploymentPro for Outlook on Workstations/Laptops
- Apply Retention/Litigation Hold if required. You would have made a note of this from your source tenant
- Users need to log out and back in
- Recreate OneDrive for Business profile
- Finally, disable access to source tenant and remove users from source when ready to do so, else you will be charged for licening
