You have decided to implement Microsoft Dynamics 365 across your global enterprise. You know the value this will bring to your organization, but you also know there are going to be challenges, especially in a global implementation.
For data stewards, architects, and product owners, data migration can be a daunting task and just one pillar of a large global implementation. The migration will affect every part of the project, from end users and developers, to testers and trainers. There are lots of questions to ask and decisions to make. How much data are we going to bring from our legacy systems? Does Germany have the same data as the UK or Singapore? What languages are represented in my master data? Do all countries sell the same products? Are all the product names and numbers the same in each country?
Undertaking a large scale, global data migration can take months or even years. In order to execute this successfully, we are going to talk about some initial thoughts and questions to prepare for in a Global Data Migration.
Step 1: Develop a Strategy
You know your destination: a single, consolidated, global system. Sounds awesome! It’s quite a path to travel in order to get there. Let’s put together a roadmap.
1. Survey Systems and People
It’s important to understand what systems, countries, and user groups are going to be part of the migration. If you envision a single global system, you need to start sharing that vision, and understanding all the pieces that will make up that system. Do we have three countries, ten, fifty? How many systems per country are we dealing with? Does everyone have their own customized system or shared systems? What users are going to be impacted? Just the sales team? Or are the call center, marketing, and IT groups impacted too?
2. Put Up Some Boundaries and Define Scope
You likely are not going to migrate every object and every field for every system part of your organization. If we do that, we will never be done. What are the critical data points that drive your business? What master data needs to be saved, what data is coming from other systems, and what data is garbage? If you ask these questions, you can identify the core data elements to focus on during the migration, saving time and money.
3. Define a Governance System
Already have a data governance group? Great! Don’t have one setup yet? Now is a good time to think about it. You are going to have many hard questions being raised by the business. “Why can’t we keep all this data?” “Why does France get to determine the values in the drop-down list?” “I absolutely ‘NEED’ this field to do my job.” All of these questions and more will be asked, and you need someone who is both informed and empowered to make these decisions quickly and definitively. Without governance, you can wind up bogged down in endless meetings, changes, and revisions with no end in sight to the migration.
4. Make a Plan for Old Data
What is your data warehousing strategy? Do you want to archive all historical data? Are you going to keep your old systems around? As previously mentioned, not everything will be migrated and you must determine whether to preserve historical data for compliance/legal reasons. Archiving can be expensive if not planned properly, but by putting some thought into this, you can potentially save historical data without breaking the bank and keep the new system lean and clean.
There are a thousand other questions that are going to be racing through your mind. This is just a framework to get started in thinking about your migration project. As we can see with just these basic points, you are going to need some help in order to get this project done.
Step 2: Assemble Your Team
You have your roadmap in your pocket, or at least the outline of one. Who is going to own this migration? Who is going to answer all the questions from the users and leadership?
The migration team is going to be as diverse as your organization. You will need representation from every country and every system. Here are some thoughts on the kind of people you might need:
- Data steward/migration project owner – At the end of the day, you need someone in charge of this migration, one person empowered to make the final decisions.
- Governance board – A group of 3-5 people who represent a cross section of the business (both business units and geographies), who are informed about the project and drive the vision of the future state of the system. This group is empowered to make decisions when users cannot decide, they also approve changes and set global definitions.
- Migration tech lead – You need someone with the technical knowledge of the various systems to help coordinate the gathering of source data, can help determine the method and approach to migration, and can take responsibility for working with both the source and target systems.
- Country leads – An individual per country who can elicit requirements from their country, but can make some decisions about what is critical and what is not. The first line of review for user requirements.
- Country techs – These are the local tech folks who know the system, can answer questions about why things are the way they are and help pull data out of their systems.
- Country users – The real source of knowledge about what the system needs to do, where data lives, and how they use existing systems. The key is finding a user or two that are real power users, and can be objective about what data they need and what they can live without. These will also be the folks responsible for validating the data once it has been migrated.