Cutover is the process of transition from current systems to Dynamics 365 business applications, whereas the strategy is not just about the data you are moving from the legacy system to Dynamics 365, but essentially a complex transition of business processes, data, system functionality, integrations, and people.
Moving to the overall approach for any cutover, it should be mentioned that it has 4 specific phases:
- Initiation – the step where you basically initiate the process defining cutover vision, principles, leader, business-focused calendar, and the strategy itself;
- Implementation – once the process has been initiated, teams need to start design and build mock cutovers creating business-focused calendar evolves, detailed cutover strategy, and migration planning;
- Preparation – the third step moves the team to the deployment and execution of final mock cutovers working on business readiness (change management, training, etc.) and production readiness assessments;
- Operations – the final steps include post-go-live cutover tasks, end-user support, triage issues, system health monitoring, etc.
Cutover Leader, Vision, and Principles
Cutover Leader
The cutover strategy should start with a cutover leader from the business who helps define and enforce the business vision and guiding principles for the cutover. There are a lot of parties involved in the process (data migration teams, change management teams, business teams, etc.) it is highly recommended to nominate the right leader right from the beginning to ensure quality and error-free cutover.
The top-notch leader will help you to unify vision as well as provide a business perspective to the cutover, not just a technical data migration perspective.
Vision
The second thing to think about is having a vision for the cutover as part of the initial cutover strategy. At the beginning of the project, you are defining a business perspective you are expecting to get out of the cutover -and not just the transition.
Are you going to be expecting the old system to get decommissioned, or is that a separate project? Are you expecting to be able to use the data from the legacy system to compare with the new one? What will be the impact on other systems? It is quite common for teams to have business requirements of the data migration poorly defined.
Needless to mention that you should keep in mind the allowable shutdown window that the business can provide. There are different techniques to apply if you, let’s say, have 4 hours on a Sunday or four days for the cutover. Defining that at an early stage will help you to avoid stumbles throughout the project.
Principles
Principles are usually defined in the initial phase and create a business-driven angle for cutovers. It will essentially corral all business users that are needed for cleaning the data, approvals, ownership, data validation, and who is going to liaise with the wider business to make sure all of those threads are connected together.
Principles assist teams to ensure cutovers are repeatable, scalable, and replicable while protecting ownership of data and security.
Business-focused cutover calendar
You have got a high-level vision, well-defined business requirements, scope definition, etc. – this is still early days and you don’t have all the answers to make the cutover as smooth as it possibly can be. The recommended solution here would be to create a business-focused cutover calendar.
The business calendar includes key business processes that the business needs to conduct around the Go-Live, ensuring the ability for teams to make adjustments to accommodate special needs for cutover should they arise during the process. There are also high-level technical tasks and milestones overlaid on the key business tasks to keep your team on track throughout the cutover.
This is a really important thing since you may not know all the details of how the technical migration will work, but you know what the business activities are going to be happening. If that’s the finance application that you are taking live, then you know you are going to be doing month-end accounting, for instance.
Creating a business-focused cutover calendar at an early stage will basically help to determine communication between the business and project, direct the cutover strategy, and identify all business constraints and requirements while preventing scenarios where the cutover being driven by primarily technical data migration perspective.
Cutover Strategy
You may not know the answers at the beginning but once you start to put more flesh on the bones as you go through the implementation phase the picture will be clear. To help you with that, here is a cheat sheet on what to bear in mind to have a good cutover strategy:
- Get your scope, requirements, dependencies, entities and etc. aligned altogether;
- Get a business calendar of activities. Not just data migration but things that are happening in the business;
- Define roles and responsibilities, and, especially, cutover leader. The cutover leader is not replacing the role of a data migration lead. Data migration lead tends to have some very specific skills to be able to drive a complex data migration. Meanwhile, a cutover leader is someone from a business perspective that is actually pulling the threads together;
- Create a high-level cutover project plan establishing the points in which you are going to do your mock cutovers, data migration trials, testing, training, and so on;
- Get initial detailed Go-Live cutover plan (including fallback plans and rules), setting formal discipline for what needs to happen;
- Determine reconciliations and what’s needed and how done to make sure the data is coming from a legacy environment to Dynamics 365 is clear and error-free;
- Get the environment management plan;
- And finally, assess the impact on the business ecosystem.