Do you want to cut down on costs when migrating to Office 365? Learn how by registering for our upcoming webinar “Save $ by Migrating More Workloads to O365!“
Editor’s Note: This blog post was updated on September 23, 2022.
It goes without saying that the logistics of merging two organizations together can be pretty tricky. This also applies to migrating data in Office 365 or merging tenants. It’s easy for data and users to get lost in the shuffle if the proper planning and validation procedures aren’t put in place in the beginning. To help make the process as smooth as possible, read on for a quick guide to migrating Office 365 data during mergers and acquisitions!
Discovery
First things first: As an admin, you need to decide which tenant is moving where. Work through all of your licensing with Microsoft. Ask yourself the following:
- Which licenses do your users have?
- What Microsoft workloads are your users using (Teams, Groups, SPO, EXO, etc.)?
- Does your destination tenant have the same workloads set up and proper licenses?
The next step is to pick a capable migration tool and run pre-discovery. Pre-discovery will give you a sense of how much content you have, what type of content you’re working with, and how “fresh” is your data. Based on that, you can take a look at your environment and determine what you’re going to move, how much you’re going to move, and where it’s going to be moved to.
The biggest merger and acquisition-specific factor to consider is naming conventions between domains. A great migration tool will allow you to import names and customize them as data moves, but it’s also important to ensure that you have a good sense of what the domain structure looks like in the source and what it could look like in the destination.
Consider: Do you want users to have the same titles in the old domain as this one? Are they merely changing domains in their email addresses, i.e. map @ABC.com to @XYZ.com? What about service accounts? Are you moving all users or just active employees?
When planning for a migration, the discovery phase is crucial to obtain an accurate understanding of your environment such as number of users, number of and what kind of containers (Teams, OneDrives, Groups, mailboxes, SharePoint sites, etc.), and combined size for each workload.
Fly now offers tenant-level discovery for a simplified and less time-consuming discovery experience. Select your tenant, choose your workspace, and run your discovery. When the scan is complete, you will see a dashboard view for each selected workspace as well as a details page where you can export, filter, and search through your findings
Request a demo to see how it works for yourself.
Build Connections
Having a connection with your source system, be it Office 365 or something else, is vital. This connection allows you to ensure you get a full-fidelity pre-discovery scan. In addition, you must build a connection to the destination, which is going to actually move your content into your new tenant. These connections must have all the access they need on both the source and the destination.
We recommend always using an app profile for moves to/from Office 365; this ensures that you’re following MSFT best practices and moving your data as efficient and fast as possible. and configuring a service account in the odd case there are things that can’t be retrieved by the app profile).
Undergoing M&A planning this year? Here's how to migrate your O365 data: Click To TweetPlan
Now it’s time to put together a plan for transitioning users and moving the content. Naturally, there’s some user management that needs to happen when moving tenants. You don’t want your users to just wake up one day and see all their documents shifted to a new tenant, have a new email address and be missing or have new workloads enabled. The main goal of Office 365 migration planning is to help mitigate any disruption to your end users and allow them to feel prepared for the switch.
Take app compatibility between tenants, for instance. If the company that acquired your organization uses Microsoft Teams but your organization doesn’t, it’s essential to fully train your users on whatever new workloads are available to them in this new post-merger/acquisition world. If there are new governance rules that must be learned, try to introduce those early on to make the transition as smooth as possible.
Similarly, if it’s reversed and your organization has been using an app that the other hasn’t, what happens to that data once you merge? Whether you decide to archive it, pull it offline, or move it over to your destination tenant, it’s best to have a plan for these migration hurdles from the outset.
Once you have laid out a plan to move users and their content, we suggest first moving the majority of user content over to the destination using a full migration, then allowing a transition period when there’s some overlap and users’ have access to both tenants. You can then perform an incremental migration to carefully bring over any loose ends or changes before a user is fully cut over to the new tenant.
This is usually a gradual process that’s often performed in groups. Depending on the size of the merger or acquisition, I recommend doing it by department. Do a pilot first with some friendly folks who’re willing to test things out with you.
Move
Some migration jobs might not get everything the first time around, so it’s vital to do analyses on all jobs that do not fully complete (i.e. jobs that complete with exceptions or just plain fail). These exceptions and failures can be due to a multitude of factors such as:
- Connection problems
- File types
- Size limits
- API limitations (likely on the source side)
- And more
It’s highly recommended to fully understand any limitations that are published on both the source and destination side. Oftentimes these are out of your control or that of your tool vendor, so this will help set the expectation with management at the onset of your migration project.
Consider the “move” a continuous loop until the project is complete and ensure that you plan for some content requiring a few passes before everything gets fully moved. Content is always going to change if users are active, and that’s okay!
Before you declare that you’re fully migrated, make sure you confirm that all the content that can be moved has gone through successfully. Third-party reporting tools can be helpful by directly telling you what’s moved and why something hasn’t moved.
Validate
Finally, you always want to validate that everything came over and review any errors that might’ve occurred during the move. This validation process will help you catch and manage anything that might’ve slipped through the cracks and carry out any lingering incremental migrations that need to be taken care of.
Note: This process will go more smoothly if users are trained to validate their own data post-migration. This is especially true if any kind of data transformation has occurred.
Common Pitfalls to Avoid
Not planning change management with your users
Again, don’t just move your users overnight without them knowing about it; it’s jarring and will make adjusting to the new tenant that much more difficult. If users come into work and magically have new workloads they didn’t have exposure to before, or if they don’t have a workload that they used to have, it’ll only cause issues.
This is why managing your users and planning your migration is so important. A key success factor in any migration is ensuring minimal disruption to your users’ workday, and it can make things much smoother if they know that their technical team is respecting that!
Not giving yourself enough time to migrate everything
Migrating content should never happen during working hours. Ideally, schedule the jobs so that they run overnight or over the weekend. This not only aligns with best practices from Microsoft, but keeps your users’ tenants running at full capacity during the workday. From there, it’s important to determine how long something is actually going to take within those limitations. If you have 100,000 workers to move, how many can you feasibly move in a given time span? Trying to squeeze a substantial migration into a short period of time will only have negative effects, such as:
- Disrupted users
- A slower tenant if too much throttling occurs
- Potential for “missing” content if there’s not enough time to remediate errors or perform validation
- Not enough runway to prepare users for what’s new or coming soon
- And so on
If you do have a tight deadline, try migrating priority content first and only very necessary data (i.e. content that is considered “active”).
Though migrating Office 365 data during a merger or acquisition can be tricky, I hope this article helps make the process go a bit smoother. And while you’re planning your migration, have you thought about how you’re going to manage the gradual influx of new users? What’s the acquiring company doing to ensure that the people, content, and workloads coming in are in alignment with the acquiring company’s governance plan?
If you want to prevent sprawl and accelerate the adoption process, give our Cloud Governance solution a look and try a free trial!
Great article, thanks! Would you know roughly the data transfer rates of a M365 tenant to tenant migration for Exchange data? For example, I have 1000 mailboxes to migrate from one tenant to another, can the pre-migration analysis in Fly migrate calculate this transfer rate or is there another method of estimating this to set the customer’s expectation?
Is it similar to Microsoft’s advise of 1 mailbox of 10Gb in size may take up to 7 days to migrate:
https://docs.microsoft.com/en-us/exchange/mailbox-migration/office-365-migration-best-practices
So the answer would actually depend on the factors Kate discusses in her article. When it comes to throughput, time of day, “business” of tenant, number of servers, throttling, are the main factors. Generally, the data size is the main indicator here, not the number of mailboxes. We would advise “throughput” on a GB/Day or GB/Hour measurement….and yes would be similar to MSFT’s recommendation, but our recommendation would be to do some testing to determine the average throughput as it varies. That would give you the best approach for estimating the job.