Tenant to Tenant O365 Migration – things to keep in mind

Reading Time: 3 minutes

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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.