Data Migration Plan: Enterprise Systems
In preparing the Project Document and the Detailed Project Plan, a few other planning documents are created including the Data Migration Plan. All systems will have some type of data to be migrated even if it’s just master data.
At the beginning of the project, before contracts are signed with implementation partners, the Project Manager in collaboration with the implementation partners and the functional leads should begin to draft the Data Migration Plan to make sure there is a clear understanding of what needs to be migrated. This impacts the scope of the project, scope of work by implementation partners, internal resource requirements, and the overall timeline.
As the new system (or systems) is (are) understood by the internal project team, and as the implementation partners and project team gain a better understanding of the business processes, the Data Migration Plan is revised and expanded to include the additional details until it is finalized prior to execution.
Waiting to create the plan may (I would argue that it will) lead to project scope changes and delays.
Who creates: Project Manager in collaboration with the functional leads and implementation partners.
Who approves: for controlled systems (SOX, GxP), approvals are generally required. For others, it depends on internal business process requirements and what was defined in the Project Document. Systems subject to SOX are approved by the functional leads and Business Sponsor. Validated systems (GxP) are approved by functional leads, the Business Sponsor, and QA in alignment with document control procedures.
When: an initial draft is generated as part of the project planning and revised throughout the project as more is learned and the data migration requirements / plan are fleshed out. If approvals are required, it is approved prior to execution.
What’s Included
Purpose: defines what is included in the document and why the document exists.
Scope: details what is and is not included in the data migration activities.
Environments / instances: provides explanation of the various environments or instances (such as Dev, Sandbox, QA, Training, and Production) including how they have been and will be used, for the in-scope system(s).
High level plan: this section summarizes the key data migration dates and activities. Note: this can extend beyond the Go Live date if there are post-Go Live data migration activities which is common with financial systems.
Data sequencing (if applicable): if the data must be migrated in a certain order, the data and key dependencies are listed here.
Data to be migrated: this will include migration preparation, migration tasks, post migration tasks including verifications, and migration dependencies.
Approvals (if applicable): I recommend that despite the controlled status of the system (SOX, GxP), that there always be an approver even if it’s just the Business System Owner. This section will have lines for the approver signature and date.
Other notes or supporting information: if there is anything else that will provide clarity on the data migration activities including the data itself, include in this section. In the case of data migration, more, rather than less, information is better.
Data migration testing summary: this section is a summary of the data migration testing that will performed or will be performed prior to migrating data into the Production instance/environment.
Other Things to Note
While the Project Manager generally drafts and manages this document, it is possible to delegate responsibility for the document to a data migration lead on the project team. Some projects have a dedicated data migration lead depending on the size and scope of the project and internal resource capabilities.
This document is owned by the client and not by the implementation partners. Most implementations partners do not become familiar with the client’s internal processes and requirements for documentation and verification.
Once the data migration plan is executed, a summary of the execution is generated in the form of a Data Migration Summary document.
How long is this document? Once again it depends on the complexity of the project. If the data migration is limited in complexity and amount/types of data to be migrated, it can be 3–4 pages. More complicated projects require more details and may be 10 pages. If it is a GxP system, and the data migration plan is a validation deliverable, it may be longer and subject to QA controlled documentation formats and processes.
Why Share This Now? Back when I was an accountant, working for my dad’s accounting firm, we had a lot of small businesses as clients. The owners of the small businesses struggled with basic bookkeeping and accounting which meant that we couldn’t add value to them and their businesses because we were so focused on the fundamentals. We created a few accounting classes for them in the form of Accounting 101, 102, 201, and 202 so we could do more with them.
I’m applying the same principles here. If I can help my clients (prospective or current) help themselves with projects and project deliverables, then I get to elevate my role beyond the day-to-day and into a strategic and advisory role which, frankly, is a lot more fun!
Check out my blog post Project Deliverables: Enterprise Systems for the complete list of deliverables with links other blog posts.
Have Questions or Require Assistance?
Feel free to reach out to Terri with any questions you might have via email at terri.mead@solutions2projects.com or through the company website SolutionsProjects, LLC.
About the Author
Terri Hanson Mead, MBA, PMP, is a technology and compliance strategist for biotech, pharma, medical device, diagnostic, and digital health companies. Through her company, Solutions2Projects, she helps life sciences companies align technology roadmaps with corporate objectives and meet IT compliance requirements in a complex and regulated industry. As an expert witness, Terri provides pre-litigation consulting and expert witness services for failed technology projects, including enterprise systems.
