Undertaking any type of migration can be a daunting and possibly costly venture for your business. Follow these five steps to help you on the way to a smooth journey.
How to Prepare for Microsoft 365 Tenant to Tenant Migration and Consolidation Projects
Hello and welcome to the Insentra series on Microsoft 365 (M365) Tenant to Tenant (T2T) migrations/ consolidations. Mergers, Acquisitions or Divestitures (MAD) and/or geo-relocation requirements drive the need for organisations to consolidate their M365 environments and these are not simple data migration projects!
We have created this series to provide a recommended approach for planning and executing a T2T project while reducing business risk. With our extensive experience gathered via hundreds of migration projects, we have identified four key focus areas to plan for to ensure a successful T2T migration and we will explore each of these in detail in this series.
These four areas cover the considerations for the Planning phase, each feeding into the next and culminating in a defined migration/ consolidation strategy:
NOTE: We are not talking about specific migration middleware technology. Only after the Planning phase is complete with specific business and technology requirements understood can a tool be selected. Pre-selection of tool(s) can force you to compromise your needs as you try to match your desired outcomes to features of a specific product.
Managing the impact to user experience will undoubtedly be a primary concern, as it should! The biggest measure of success or failure in these projects is the user impact. Data may be moved correctly but if a user isn’t prepared for the changes or has issues at cutover (such as logging in or a policy or process change which wasn’t communicated properly) then their perspective will be the project went poorly. To ensure this doesn’t happen, proper stakeholder management and communication is paramount.
It is safe to say, the longer a tenant has been in place, the more planning and considerations there will be. So, let’s unpack some of these considerations:
- Stakeholders –Different stakeholders will have their own unique needs with some wanting it over as quickly as possible and others wanting to ensure a thoroughly planned and executed migration. The first part of the process is to identify and understand these needs so, where possible, they can be addressed and/ or managed.
- Project timing –Businesses undergoing a MAD generally have time constraints put in place by those pesky lawyer types, often with significant impact on the project. To overcome this, it is critical to ensure a strategy is built which allows for more time spent planning at the beginning which then enables acceleration of the project and completion quickly and correctly, first time.
- Risk Appetite – What is the risk profile of the organisation and the stakeholders? Every project involves risk but reducing it can often mean additional time and money. For example, do we need to spin up a secondary environment and test an application migration first, or is the risk it doesn’t work on day one acceptable?
- Communication – Excellent communication with stakeholders, champions and users means smooth sailing! If we don’t communicate with stakeholders during the planning phase, we may miss an integral business process from the discovery. Similarly, if we don’t communicate upcoming changes with users, they may not know how to do their job in the new environment. The best way to do this is to build a communications plan which maps out all of the messages over the course of the transformation…….ADKAR anyone?
After we have done our due diligence on the user experience it is time to take this information and consider the Identity piece. All hail identity!
Identity is the core construct underpinning tenant to tenant projects. Identity controls permissions, access to applications and data, business processes, the security and data governance. Every environment is different so our user experience inputs are critical in defining what identity will mean to the business. Here are some of the areas to understand in order to form a wholistic identity picture:
- Overarching identity approach – Understanding the approach for identity allows for the planning of the correct end-state first time. Is the approach to migrate existing accounts, create new ones, consolidate accounts together or even operate with two separate accounts for a period? What will be the overhead and experience when making changes during a migration such as onboarding new users? Making a mistake around identity can be extremely hard to fix during or after migration - even something small like how access is granted to resources can be tough to change. The recommended process here is to discuss and agree the approach to ensure it maps to the desired end-state.
- Governance – Governance can mean a lot of things, however here we are specifically referring to the processes and rules for how your organisation governs identity. A sample of the things to consider includes: What is the process for requesting access? Who approves and how? What about replicating governance structures in the target – will there be new procedures adopted or the same ones being used? What are the implications if there is a change in process?
- Security – Security is driven by identity, so it fits in well here. All aspects of security which are relevant or could change during the project must be addressed given the significant business impact from security oversights or breaches. The world has seen security incidents completely wipe out companies in recent times and in our experience, companies are still not taking security seriously enough. Multi-Factor Authentication is one of the most impactful ways to reduce security risk – so we make sure we have that covered during these projects. A T2T project is also a perfect time to possibly undo some previous decisions and further tighten the security posture in the organisation. Security must be carefully planned and reviewed frequently.
- Policies and processes – What is being moved from and to from a policy and procedure perspective? This can cover technological changes as well as fundamental process changes. An example might be order processing where a PowerApp in the source environment might rely on a component which isn’t being migrated, or a policy for personal use of devices meaning traffic is logged in the new environment. All of these need to be mapped out. Missing a critical business process could have large implications to business operations after completion.
Once a picture of identity and user experience has been established the remit needs to be widened to include all of the potential integrations. Personally, I like to talk about interferences – or potential blockers – as well. However, blockers are only blockers until they aren’t!
So, let’s address the wider technology footprint which will be impacted by the project.
- Core systems – In some cases this is very straight forward, but it still needs to be documented. Examples could include a CRM system which is integrated with Microsoft 365 for authentication and emailing out to customers, or a helpdesk system which relies on a mailbox to log tickets in Exchange Online. Other, not so straight forward examples need more investigation, particularly when systems also need to be split, removed or replaced with something else entirely.
- Deciding criticality – Once a list of systems is established it’s important to classify them so they can be given the appropriate attention. This goes back to risk appetite which helps determine if more time and money must be spent on the validation and testing of certain systems.
- Integrating (or de-integrating) systems – In the MAD world the systems in place today either need to be split, joined, or potentially completely new systems have to be provisioned. An example might be a CRM system where one business is divesting from another. The system will have both businesses data, customers and opportunities which need to be carefully dissected to ensure the correct data is migrated. This isn’t always a bad thing as it is one place where improvements can be made during the process (and there are quite a few of those!)
Building a Strategy
The number one consideration when undertaking any complex project is to ensure a detailed strategy is in place and agreed to by all stakeholders. T2T projects are complex, particularly when there are multiple entities or geographies to consider. The core concepts above act as perfect inputs to start building the path forward.
Here are the main themes to consider in documenting the strategy:
- Organisational Overview – The entire strategy being built has to fit the needs. Documenting the correct stakeholders, risk tolerance and any overarching MAD requirements or drivers is critical to ensure alignment.
- End-state requirements – Clarifying the end-state requirements is important because it represents success. The information gathered on core systems, policies and procedures, security and more can be used to ensure the requirements match expectations.
- Change management – Detailing the Change Management approach, communications, risks, threats and opportunities is paramount to a successful T2T project. This part of the strategy will likely be the project managers favourite! Its main purpose is to reduce the risks associated with changes to an environment. In practice, this could be things as simple as ‘external sharing won’t migrate so we must communicate this’ or as complicated as ‘managing the data governance risk for intellectual property will be done this way.’ This information is used to determine the way to mitigate the impact of the identified issues/risks and create a detailed communication and risk management plan.
- Discovery – Documenting what has been uncovered in each of the existing environments through use of toolsets, manual discovery, workshops and interviews ensures all things have been captured. Mapping this information to the end-state requirements to provide a direct relationship between what exists, the integrations discovered and the end-state then allows for the identification of any gaps and the ability to document the relevant plans to address.
- Migration Approach – This is the detail regarding the most suitable migration approach including a RACI, timelines, impacts and the actual migration process.
Now the core considerations have been covered and a strategy framework built, it’s time to start the process of selecting the migration tool which best fits the requirements. As mentioned previously, the reason not to lead with a tool is because the tool selected needs to be the best one for the job, not the job for the tool. Future blogs in this series will explore how to conduct the migrations as well as addressing the many roadblocks which could be encountered along the way.
Please reach out if you have any questions and make sure to explore our other tenant to tenant migration materials.
Join the Insentra Community with the Insentragram Newsletter
Hungry for more?
Archive Migrations – How does the Insentra Train do it?
The information landscape has been constantly evolving and so have solutions around the management of the same. We must keep progressing but the first thought that comes to our mind is the long journey we must endure, i.e. “Do I need to go down this road again?”.