Below are things to consider when planning a tenant to tenant migration using MigrationWiz. MigrationWiz is a cloud service provided by BitTitan. There are other services out there that you can research.
1) URLs change for SharePoint Teams, and OneDrive so previously 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. OWA can easily be forgotten about 🙂
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 a record of these details
12) Mailbox litigation hold don’t migrate so ensure you have a record of these details
13) Mailbox full permissions don’t migrate so ensure you have a record of these details
14) Mailbox Send As don’t migrate so ensure you have a record of these details
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 will need to recreate guest accounts if they were in use at source tenant and there is a requirement for these at destination
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. The pre cutover copy will be much faster if most of your data has already been copied
23) If you have a lot of data and in a rush to migrate users, 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 if you have a large number of users. 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. If you have a small number of users you could deal with outlook profiles manually
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 mail filtering, 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 (email filtering, 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.
30) O365 groups don’t migrate. These need to be recreated
31) Mail contacts don’t migrate
32) Mailbox Delegation don’t migrate (SendAs, Send on Behalf Of, and Full Access).
33) Mailbox permissions don’t migrate
34) User calendar permissions don’t migrate
For more info on a O365 tenant to tenant migration visit Tenant to Tenant O365 Migration
