When two companies combine through a merger or acquisition, you might treat the migration between them as a technology challenge. You’ll have multiple software solutions, different ERP solutions, maybe even different clouds involved, and your task is to combine it all and make it work – with minimal disruptions to critical systems. You’re building the new plane while you’re already in the air, and that’s not an easy task.
Having overseen dozens of tenant-to-tenant migrations across Microsoft 365, Dynamics 365, and Azure, I see most often that there are many non-technology factors involved as well, and these are sometimes neglected. By addressing these factors through the assessment, planning, and execution of the migration, you’ll find that you can minimize the impact of the migration and even find some unexpected benefits.
Communicating Effectively
Communication is key. From the top executive to the end-user, everyone involved in the migration needs to know what is happening, why it’s happening, and how it will affect them and their day-to-day business environment.
You’ll need to ensure consistent communications that align with the new organization’s voice throughout the process. This is why it’s essential first to establish best practices and policies for the entire entity to ensure that messaging is coherent throughout the process. Step-by-step instructions from start to finish to all users are necessary to ensure as little business disruption as possible.
Managing Change
A merger or acquisition can be alarming for everyone involved, and the concerns and fears of employees can directly affect the migration. Some people will resist the assessment process – few like the idea of being inspected, and almost everyone feels like their way of doing things is the right way. Change isn’t easy.
Regardless of the technology, be it M365, D365 or Azure, your goal in a tenant-to-tenant migration is to bring the best of breed from both sides, while ensuring that their business can continue with minimal turmoil before, during, and after the migration. That means that you have to ask the right questions, at the right level of detail. It means listening to workers to understand their needs. And to be effective, change must have a holistic view; if you allow business areas or projects to remain in silos, they can seriously harm (or be harmed by) the migration.
Identifying Opportunities
Here’s the really good news: a merger or acquisition can be an ideal opportunity for optimization – eliminating application and software duplications, reducing unnecessary components, and ultimately minimizing the outlay for technology.
But it can be a complex process to understand the needs of each user.
The path forward may include a best-of-breed approach or replacement across the board, but it must be managed to ensure that the end-users feel heard and their needs are met.
This starts with analyzing users’ business activities, what they need to accomplish them, and figuring out the best tools for the job. Another key opportunity for optimization is the chance to evaluate current software purchasing vehicles such as traditional Licensing Solution Provider (LSP) resellers to potentially take advantage of the more flexible Cloud Solution Provider (CSP) models. At the end of the day, your new organization’s desired result is to emerge with an optimal licensing and software footprint that minimizes spend – maybe even saves you money.
Finding the Right Advisor
With all of these non-technical challenges to address as you approach your migration, you’ll have one more consideration: how to get help. An experienced third party who can lead the assessment, planning, and execution is essential to the success of the migration effort.
While an advisor has to bring a strong technology background to the migration effort, this may not be their most important benefit to this work. Instead, their key role is as an objective assessor, taking an unbiased view of both companies involved in the merger, and assessing them fairly to get a clear picture of the best path for the new, combined entity to go forward. A good advisor will act as a mediator, ensuring all the voices involved are heard, and helping to develop a migration plan that is to everyone’s best advantage in the end.
Embarking on Your Tenant-to-Tenant Migration
The COVID-19 pandemic has caused substantial consolidation in many industries, and Quisitive has helped many organizations to complete their mergers or acquisitions with successful tenant-to-tenant migrations.
Our expertise with cloud technologies and the Microsoft product stack is only part of these positive results. Our understanding of the migration process, and the non-technological factors that successful migrations depend on, have been just as crucial in achieving these outcomes.
So as you prepare to embark on your migration journey, Quisitive is here to help.
Learn more about our On-Ramp for Mergers, Acquisition, and Divestitures Program.
Explore our other content about tenant-to-tenant migrations:
- Blog Series: What to Expect When Undergoing A Tenant to Tenant Migration
- Case Study: Quisitive Drives Tenant-to-Tenant Migration for Omnitracs
Over the last two parts of my series on tenant to tenant migrations, I’ve covered what happens before and during a migration. In this article, we’ll look at what to consider after a migration.
Common Post-Migration Challenges
Like a couple moving in together, a tenant to tenant migration can be exciting, but it’s also challenging. The combined furniture might not match well. The layout of a room might be different than it was before. Getting used to the new environment can take some time and it doesn’t always go smoothly.
Hiccups can occur after a tenant to tenant migration.
For example, sometimes not everything properly ports over in a user’s profile. The signatures, rules, and autocompletes might break during migration. An autocomplete might point back to the old system, which can cause frustration and confusion for the user. While it’s fixable, it’s an example of something that might not be considered from the outset, which is why it’s so important to work with an experienced partner like Quisitive throughout the entire process.
On top of communicating change is enabling learning for the newly migrated users. If they are receiving new applications or tools, they need to understand their functions, usage, and benefits through dedicated training in order to effectively make use of them.
Regardless of how smooth a migration such as this goes, skipping the change management step can cause chaos, frustration, and employee dissatisfaction. It’s as important as any other element of the migration process.
Tenant to Tenant Migrations for Divestitures
If a tenant to tenant migration, due to a merger or an acquisition, can be likened to a couple moving in together, a divestiture can similarly be compared to a divorce. It doesn’t mean that it’s acrimonious or unhappy, but complications can arise when splitting up an organization into two entities. The fact is, it’s often easier to move one tenant into another than it is to separate one.
Why? For a number of reasons.
First, both organizations, regardless of how long they have been inhabiting the same tenant, likely use shared data and shared databases. Like a divorce, when books are divided based on whose name is written inside the front cover, a divestiture requires close scrutiny on what belongs where.
For example, to accurately separate data, close inspection is required on which organization is using what. This often comes down to inspecting databases, applications, and even specific tables.
The trick, when it comes to divestiture, is knowing how to divide these assets while trying not to negatively impact the users left behind when it comes to productivity, activity, and usage. The fact is, while it’s critical to try to minimize the impact on end-users as much as possible, there is the potential for greater impact on users during a divestiture than during a tenant to tenant migration.
To mitigate these risks, we take all of these factors into consideration during the assessment phase of our engagement. Like with a tenant to tenant migration, we conduct a deep assessment for a divestiture scenario to ensure that a migration out of a tenant is as successful as a migration into one. We look at an organization’s assets, usage, and activity with objectivity and a data-based approach in order to provide the best possible recommendation to the client.
While a tenant to tenant migration –– or emigration, in the case of a divestiture –– is a complex process, using the right partner can ease the journey. At Quisitive, we’re well versed in the processes, tools, and strategies for guiding organizations through this journey. We have the experience, expertise, and knowledge to help make any tenant to tenant migration a success.
Want to learn more? Click here to explore our On-Ramp to Microsoft 365: Tenant to Tenant Migration program.
A tenant to tenant migration is a complex and often challenging process. From the very decision of which tenant will become the new host, every step is critical to achieving success. In the case of a tenant to tenant migration, the devil really is in the details.
Considerations around tenant naming convention
In the first part of this series on tenant to tenant migration, I focused on the many considerations prior to starting the migration process. One that I didn’t cover is around the existing tenants’ naming convention. Each tenant already has an individual name so when one tenant moves to the other, they adopt that tenant name.
In some situations, this may not be ideal. For example, a customer might see the tenant name when sharing files, which the company might not want. Or, if the company wants to take a particular marketing approach, they may not want to expose the tenant name — they might want it to be more generic.
In this instance, the two entities might not migrate to one tenant or the other but instead choose to create a third tenant, known as a greenfield tenant. In this scenario, both companies must migrate their data to this new tenant, essentially starting from scratch.
The greenfield approach
While taking a greenfield approach can be more complicated than migrating one tenant to the other, there are some significant benefits to doing so. For example, if a holding company is in the business of acquiring and selling companies, a tenant with a generic name is easier to roll a company into and migrate into their organization.
One of the most important migration activities is properly transitioning email from two domains to one. Ideally, to migrate email from one tenant to the other, we use specific tools to scan the source tenant and create mail-enabled contacts and create coexisting calendars between both tenants.
Unfortunately, this is often a step that becomes complicated by an eager IT person at one of the two organizations. Because email is so critical to a business, it’s one of the first considerations when thinking about a tenant to tenant migration, so that helpful IT person might proactively start creating new email accounts in the target tenant before the users are properly prepared to be migrated over.
While it is always done with good intentions, the problem with this scenario is that it can become a “gotcha” when completing the actual migration. Implementing something like new email addresses without consultation can cause complications for smoothly transitioning one company’s email to the other’s, often leading to a loss in email data, either from the existing account or from the newly created account.
Another common complication is discovering third party integrations during the process. For example, in Outlook, some departments may have implemented third-party add-ins that do certain things to benefit their work. A marketing or finance department may have added in tools to help with invoicing or email distribution. The problem with these add-ins, from a tenant to tenant migration perspective, is that they have the potential to break the client while doing the migration if they’re not addressed properly.
Importance of understanding tenant usage during assessment phase
The best way to avoid these kinds of surprises is to have a good handle on who’s using what within the tenant. While this can be a challenge for large organizations, it’s something that we delve into during the assessment phase of the migration process.
A tenant to tenant migration is much more than a lifting and shifting of applications and data from one cloud to another. It requires precision, attention to detail, and covering every possible scenario.
In Part 3 of my series on a tenant to tenant migration, I covered some of the post-migration considerations as well as how to handle the reverse scenario — a divestiture. You can read part 3 here.
Click here to learn more about the On-Ramp to Microsoft 365: Tenant to Tenant Migration program. Ready to transform your corporate budgeting, planning, reporting & corporate performance management? We can help! With over 30 years of experience helping companies implement and optimize corporate performance management software, our team of experts is here to help analyze your existing processes and recommend the right solution to meet your needs.
A merger, acquisition, or divestiture inherently triggers change across not only one, but potentially multiple organizations. It requires a multitude of decisions — from staffing to branding to capital consolidation. One of the most challenging decisions, for many organizations, involves a tenant to tenant migration.
A tenant to tenant migration, in its simplest terms, is moving one company’s cloud contents to another, so that both entities can access all, not just some of the data, applications, and tools stored there.
While that might sound like a minor task, tenant to tenant migrations are in actuality a complex process that involves data-based decision making, and a deep assessment of both cloud environments. Why? Because the decision to move content from one tenant to another doesn’t necessarily default to the bigger brand, the larger company, or the organization doing the acquiring. If done properly, it’s based on facts.
The first step in the assessment is to get an accurate snapshot of each tenant and assign scores to each. During the assessment, we look at a number of different elements, including who is using what applications within each organization. We tabulate the active workloads and then determine both the usage and the productivity for each of these workloads.
For example, we might hone in on the usage of Microsoft Teams within a tenant. How many people are using it? Which departments are they in? What are they using it for? What other workloads are they using with it? How much time do they spend on Teams per day? Per week? Per month?
We also find commonalities and differences between the tenants. If one uses multi-factor authentication and the other doesn’t, we may have to enable it on the tenant that isn’t using it if the decision was made to migrate to that tenant in order to allow for a smoother transition. The same might go for Yammer or any other number of workloads or tenant configuration settings.
By breaking each tenant down into individual workloads, we’re able to take an objective approach, versus a subjective one, when determining which tenant should become the new host. Sometimes that decision isn’t expected or even welcomed by the organizations involved, but having the data to make the case for the move in one direction or the other is often necessary and makes the decision difficult to dispute.
Once that decision is made — and it should happen within the first few weeks of the pre-migration period — it’s time to dig in and begin prep work. This includes a number of tasks such as resolving any issues that were discovered as part of the tenant assessments, creating a master list of users and mailbox mappings, recording all accepted domains, purchasing migration tool licenses, running Health Checks for Office 365, and planning for domain cutover, just to name a few.
Having a pre-migration checklist is critical to a successful tenant to tenant migration. I have trained as an instrument-rated pilot and preparing for a tenant-to-tenant migration reminds me of my flying days. Before you ever get off the ground, you need to go through an extensive flight checklist one item at a time to make sure that all systems are ready to go, and you’re prepared for take-off.
In Part 2 of this series, I’ll talk about what cutover day looks like, and the process of moving Office 365 mailboxes from one tenant to another.
Click here to learn more about the On-Ramp to Microsoft 365: Tenant to Tenant Migration program.