I’ve often been asked by customers about planning a migration, which is an important and complex topic. Each enterprise typically has its own strategy and roadmap for transitioning to cloud platforms and integrating AI and Machine Learning models with existing data.
Here, I’ll outline the key considerations I would take into account if a customer were to ask for advice on planning the migration of their enterprise system. For this example, I’ll focus on Dynamics 365 CE, though the process is similar for other systems.
Types of Migration
Migration can generally be divided into several scenarios. Here are a few common types: a. From on-premises systems to the cloud. b. From a similar CRM system (e.g., Salesforce) to Dynamics 365 CE. c. From a third-party or self-developed app to Dynamics 365 CE. d. Greenfield setup (brand new implementation).
Migrations involving scenarios (c) and (d) are typically more straightforward, as they usually involve brand-new setups. Scenarios (a) and (b) require more in-depth analysis and planning, so I will focus on these two here.
The diagram below (not included here) outlines a typical enterprise system architecture, showing the complexity of thousands of applications running concurrently. This can serve as a useful reference when considering migration and how various systems interact.
Migration Planning Process
1. Categorize the Migration Type
Once the migration type is identified, the next step is to perform an “As-is” analysis of the existing system. This involves assessing the current integration between systems, identifying connector types, and noting if any custom development has been done. Workshops with both functional and non-functional system owners will help document this thoroughly.
2. Collect CRM System Information
For the CRM system, specific information needs to be gathered, such as the system version, database profile, active modules and functions, number of users, web services used, BI flows, and the business units involved.
3. Analyze the Technical Stack
Next, the technical stack for any existing portals or websites should be reviewed. For example, is JavaScript being used? What technologies power the eCommerce site, like PHP, and which version?
4. Evaluate Customizations and Business Processes
How much of the CRM system relies on out-of-the-box functionality versus custom development? This includes understanding plug-ins, workflows, the security model, and the organizational setup (e.g., business units and teams).
5. Review UI/UX
It’s important to identify the technologies used for the user interface, such as JavaScript or jQuery.
6. Data Considerations
One of the most critical factors is the data itself. This includes understanding the data size, the data processing workflow (e.g., ingestion, preprocessing, ETL to a data warehouse), and the tools that will be used for migration, such as Scribe, KingswaySoft SSIS, or even Excel.
Timeframe and Documentation
This discovery and assessment process can take weeks or even months, depending on the complexity of the existing environment. At this stage, a comprehensive document should be created and signed off by key stakeholders. This document will serve as the foundation for all upcoming migration tasks.
Stakeholder Collaboration and Planning
Throughout the process, numerous sessions with product owners and stakeholders will be held to define the target environment. Key elements to confirm include basic settings, processes, customizations, web services, data, user and content migration, as well as system integration and dependencies. This information will help prioritize and outline the specific migration tasks.
Customization and Testing
Sandboxing and pilot testing will be performed to ensure that customizations and UX are aligned with the expectations of users and stakeholders. After multiple workshops, two key documents will be created: one detailing the “As-is” (current environment) and the other outlining the “To-be” (target environment). The “To-be” document will ensure that all details from the current environment are properly mapped and addressed in the new system.
Migration Execution and Testing
In parallel with the planning, another workstream will detail the migration for each application, specifying the order of migration, rollback plans, cutover plans, and even blue-green deployment strategies if needed. The migration document will also include the testing plan with acceptance criteria.
Final Tuning and User Experience
Once migration is complete, the final step is tuning the system for performance and optimizing the user experience.
Conclusion
This is a high-level overview of the migration process, which requires the involvement of people across all levels of the organization and demands extensive communication throughout. I hope this gives a helpful framework for those preparing for an enterprise system migration.