This is a ready-to-use plan for the strategic and cutover-execution side of a GxP data migration, separate from the field-level mapping and reconciliation detail. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template. This is general guidance to adapt and verify, not legal or regulatory advice; confirm each cited regulation against the current source before you rely on it.
This plan answers the questions that come before any field gets mapped: what model of migration is this, what happens to each data class, who owns which decision, and what exact sequence takes the organization from two systems holding the truth to one. The field-by-field mapping, extract-transform-load verification, and reconciliation detail live in a separate data migration validation protocol; this plan points to that document rather than repeating it.
Document control header
| Field | Entry |
|---|---|
| Document title | Data Migration Strategy and Cutover Plan for <<FILL: source system to target system>> |
| Document number | <<FILL: PLAN-ID, e.g. PLAN-VAL-018>> |
| Version | <<FILL: version, e.g. 1.0>> |
| Effective date | <<FILL: effective date>> |
| Supersedes | <<FILL: prior version or "New">> |
| Document owner | <<FILL: role, e.g. Validation Lead>> |
| Source system / target system | <<FILL: source name, version>> to <<FILL: target name, version>> |
| Linked risk assessment | <<FILL: RA document number>> |
| Linked migration specification | <<FILL: mapping document number>> |
| Linked validation protocol | <<FILL: data migration validation protocol number>> |
| Planned cutover date | <<FILL: date, or "TBD, gated by dry-run results">> |
1. Purpose
This plan defines the migration model, the disposition of every in-scope data class, the roles and decision authority, the source freeze and system-of-record strategy, the rollback and contingency philosophy, and the sequenced cutover runbook for moving GxP data from <<FILL: source system>> to <<FILL: target system>>. The objective is that everyone involved in cutover, from the person who flips the freeze switch to the quality unit signing the go/no-go decision, is working from the same sequence and the same acceptance philosophy, agreed before the pressure of cutover day.
2. Scope
This plan covers the strategic and execution decisions for the migration named in the header: the migration model, the migrate/archive/retain classification for every data class, roles, the freeze and system-of-record strategy, rollback philosophy, and the cutover runbook through go-live.
It does not cover: the field-by-field mapping and transformation rules, governed by the migration specification (<<FILL: mapping document number>>); the extract-transform-load verification and the count, checksum, and sampling reconciliation, governed by the data migration validation protocol (<<FILL: protocol document number>>); the risk scoring behind the verification depth, governed by the data migration risk assessment (<<FILL: RA document number>>); or the decommissioning of the source system after the target is proven, governed by <<FILL: decommissioning plan document number>>. Where this plan and one of those documents appear to disagree, this plan’s disposition and sequence govern and the disagreement is resolved and recorded.
3. Approach
3.1 Migration model
State the model and the reason. A big-bang migration cuts over every in-scope data class at once on a defined date; it is simpler to reconcile but has no partial fallback. A phased migration moves data in tranches (by site, by record type, by date range); it reduces the blast radius of any one cutover but creates a window where the same data class can exist in two systems, which makes the system-of-record rule in section 7 mandatory rather than optional.
| Item | Entry |
|---|---|
| Model chosen | <<FILL: big-bang / phased>> |
| Rationale | <<FILL: why this model fits the data volume, downtime tolerance, and risk profile>> |
| If phased, tranches and sequence | <<FILL: tranche definition and order, or "N/A">> |
3.2 Data classification: migrate, archive, or retain in legacy
Every data class from the risk assessment gets one disposition. A class left undecided is the gap an inspector finds.
| Disposition | When it applies | What this plan requires before cutover |
|---|---|---|
| Migrate to target | Active records still in operational use | Mapping approved, tooling qualified, dry run passed, verification depth set by the risk assessment |
| Archive to a validated repository | Records past active use but within retention | Archive format, location, and retrieval demonstrated per <<FILL: archive procedure / decommissioning plan reference>> |
| Retain in legacy (read-only) | Migration not feasible or not worth the risk for this class | Legacy system stays accessible, supported, and access-controlled for the full retention period; named owner for that support |
| # | Data class | Disposition | Owner | Notes |
|---|---|---|---|---|
| 1 | <<FILL>> | <<FILL: migrate / archive / retain>> | <<FILL>> | <<FILL>> |
| 2 | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
| 3 | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
“Retain in legacy” is a legitimate answer for a small volume of complex historical records, but only when someone owns the legacy system’s patching, access control, and retrievability for the full retention period. Recording “keep the old server around” with no named owner is the same as not deciding.
4. Roles and RACI
| Activity | Business / Process SME | IT / Migration Engineer | Validation | QA |
|---|---|---|---|---|
| Confirm data class disposition | A | C | R | C |
| Approve migration model | A | C | R | A |
| Define source freeze and baseline strategy | C | R | A | C |
| Define system-of-record rule during overlap (phased only) | A | C | R | A |
| Execute cutover runbook steps | C | R | R | I |
| Go/no-go decision | A | C | C | A |
| Authorize rollback or contingency | A | C | C | A |
| Release target as system of record | C | I | C | A |
R = responsible, A = accountable, C = consulted, I = informed. Name individuals against these roles for this migration; a role owned by a function is owned by nobody when a decision has to happen at 2 a.m. during cutover.
| Role | Name |
|---|---|
| Migration lead | <<FILL>> |
| Business / data owner | <<FILL>> |
| IT / migration engineer | <<FILL>> |
| Validation | <<FILL>> |
| QA approver | <<FILL>> |
| Go/no-go decision authority | <<FILL: named role, e.g. QA Head plus Migration Lead jointly>> |
5. Source freeze and baseline strategy
| Item | Entry |
|---|---|
| Freeze method | <<FILL: read-only mode, disabled writes, or a defined cutoff timestamp with a documented reconciliation of any late change>> |
| Freeze window | <<FILL: start and end date/time>> |
| Baseline snapshot | <<FILL: how and when the source baseline count and checksum are captured, referencing the validation protocol's extract verification>> |
| Communication of freeze | <<FILL: who is notified, how, and how far in advance>> |
A source that keeps changing under a migration in progress cannot be reconciled cleanly. Freeze the in-scope classes for the freeze window, or capture and reconcile any delta deliberately as its own step; do not let “we’ll catch it in reconciliation” stand in for an actual freeze decision.
6. Deliverables this plan depends on
| # | Deliverable | Document number | Status at plan approval |
|---|---|---|---|
| 1 | Data migration risk assessment | <<FILL>> | <<FILL: approved / in progress>> |
| 2 | Migration specification (field mapping) | <<FILL>> | <<FILL>> |
| 3 | Data migration validation protocol (ETL verification and reconciliation) | <<FILL>> | <<FILL>> |
| 4 | Dry-run / trial migration report | <<FILL>> | <<FILL>> |
| 5 | Decommissioning plan for the source (post-cutover) | <<FILL>> | <<FILL: not started until target proven>> |
This plan does not proceed to production cutover (section 8) until items 1 through 4 are approved and the dry run in item 4 has passed. Item 5 begins only after the target has proven itself in operational use; it is not a cutover-day activity.
7. System-of-record rule during any overlap window
Applies to phased migrations, and to any big-bang migration where a defined subset of users continues touching the source during a short cutover window.
| Item | Entry |
|---|---|
| Which system is authoritative for each in-scope class during the overlap | <<FILL: per tranche, name the system of record and the date it changes>> |
| How double-entry or double-counting is prevented | <<FILL: e.g. source set read-only for a migrated tranche the moment it is verified>> |
| How users are told which system to use, and when | <<FILL: communication plan>> |
An overlap window with no stated system-of-record rule is where duplicate records and silent divergence come from. State the rule before the window opens, not after someone asks which system has the correct answer.
8. Acceptance philosophy
| Item | Entry |
|---|---|
| Completeness acceptance | <<FILL: e.g. 100 percent count reconciliation for every class, every variance explained and approved>> |
| Accuracy acceptance | <<FILL: per the risk assessment's assigned verification depth per class; no unresolved Critical defect>> |
| Who judges acceptance is met | <<FILL: QA, based on the reconciliation report against the protocol's acceptance criteria>> |
| What a failed acceptance triggers | <<FILL: deviation, root cause, correction, re-verification of the affected class; no partial release>> |
This plan states the acceptance philosophy at the strategic level; the specific pass/fail criteria per check live in the data migration validation protocol referenced in section 6.
9. Rollback and contingency philosophy
| Item | Entry |
|---|---|
| Rollback trigger | <<FILL: e.g. any Critical defect open at the go/no-go gate, completeness reconciliation fails, cutover runtime exceeds the window with no safe stopping point>> |
| Rollback method | <<FILL: restore target to pre-migration state / keep source as the system of record and re-attempt on a later date>> |
| Rollback tested before cutover | <<FILL: yes, reference the dry-run or rehearsal evidence>> |
| Decision authority to invoke rollback | <<FILL: named role(s), matching section 4>> |
| Communication on rollback | <<FILL: who is told, how fast, and what they are told to do in the meantime>> |
A rollback path that has never been rehearsed is a hope, not a control. Confirm it works before cutover day, not during it.
10. Cutover runbook
Sequence the production cutover as a controlled change. Fill in the owner and evidence reference for each step; do not skip a step because a rehearsal made it feel routine.
| Step | Action | Owner | Evidence |
|---|---|---|---|
| 1 | Announce freeze; stop writes to the source for in-scope classes; capture the baseline snapshot and counts | <<FILL>> | <<FILL>> |
| 2 | Confirm pre-cutover backup of the target is taken and verified restorable | <<FILL>> | <<FILL>> |
| 3 | Run the production migration; capture execution logs and the reject/error log | <<FILL>> | <<FILL>> |
| 4 | Run completeness verification: counts, referential integrity, reject log review | <<FILL>> | <<FILL>> |
| 5 | Run accuracy verification per the risk assessment’s assigned depth per class | <<FILL>> | <<FILL>> |
| 6 | Produce the reconciliation report; disposition every exception (re-migrate or document an approved exclusion) | <<FILL>> | <<FILL>> |
| 7 | Quality unit reviews against the acceptance criteria in section 8 and section 9 of the protocol; records the go/no-go decision | <<FILL>> | <<FILL>> |
| 8 | On go: release the target as system of record, notify users, update the system-of-record rule per section 7. On no-go: execute the rollback or contingency from section 9 and re-plan the cutover date | <<FILL>> | <<FILL>> |
| 9 | Keep the source in a recoverable, read-only state; do not begin decommissioning activities | <<FILL>> | <<FILL>> |
| 10 | Schedule a post-cutover check (<<FILL: interval, e.g. 2 weeks>>) confirming the target is operating correctly in real use before any decommissioning planning starts | <<FILL>> | <<FILL>> |
For a phased migration, repeat steps 1 through 9 per tranche and maintain a master tranche-completion view so the final state is provably the sum of the parts with no gaps or overlaps.
11. Go/no-go gate criteria
Cutover proceeds to release (step 8, “go”) only when all of the following are true and evidenced.
| Criterion | Requirement |
|---|---|
| Completeness | Every in-scope class reconciles per section 8; every variance explained and approved |
| Accuracy | Verification depth per the risk assessment met for every class; no open Critical defect |
| Reject log | 100 percent reviewed and dispositioned; no unexplained record loss |
| Rollback readiness | Confirmed available per section 9, not merely documented |
| Quality unit review | Reconciliation report reviewed and the go/no-go decision recorded by the authority named in section 4 |
A single open Critical defect, or an unexplained count variance, is a no-go. There is no partial go.
12. Deviations and handling
Any departure from this plan, any reconciliation failure, or any data loss discovered during cutover is documented as a deviation per <<FILL: deviation SOP-ID>> and assessed for impact before proceeding to the next runbook step. Do not release the target for GxP use while a deviation affecting migrated data remains open.
13. References
21 CFR Part 11 (electronic records and electronic signatures). 21 CFR 211.68, 211.180, 211.194. EU GMP Annex 11 (Computerised Systems). EU GMP Annex 15 (Qualification and Validation), 2015 revision, for change management of the cutover. MHRA GxP Data Integrity Guidance and Definitions. PIC/S PI 041, Good Practices for Data Management and Integrity. ICH Q9(R1), Quality Risk Management. GAMP 5 (Second Edition), for the migration lifecycle and risk-based approach.
Confirm the current version and clause numbers of each reference before issue.
14. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
15. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (Migration lead) | <<FILL>> | ||
| Business / data owner | <<FILL>> | ||
| Validation | <<FILL>> | ||
| Approver (QA) | <<FILL>> |
Filled specimen
The following shows the strategic decisions and cutover runbook completed for an example migration of a legacy quality management document repository to a new cloud-hosted QMS, so you can see the level of detail an inspector expects. The company, systems, and numbers are illustrative; replace them with your own.
| Field | Entry |
|---|---|
| Migration | Legacy on-premise document repository (12 years of controlled documents and records) to cloud QMS, single production cutover |
| Model chosen | Big-bang, over a planned four-day weekend downtime window; volume (38,000 controlled documents, 210,000 records) and interdependency between document and record modules made a phased split impractical without duplicating the workflow engine |
| Disposition | Active controlled documents and open records: migrate. Superseded documents past their retention trigger: archive to the validated document archive. Closed CAPAs older than 10 years, already exported once for a prior audit: retain in legacy, read-only, IT-owned, reviewed annually for continued accessibility |
| Freeze | Read-only at 18:00 Friday; baseline snapshot and counts captured immediately after freeze; users notified two weeks prior and again the morning of |
| System of record during cutover | Legacy system remains system of record until the go decision is recorded Monday 09:00; no user access to either system between the freeze and the go decision |
Cutover runbook result:
| Step | Result |
|---|---|
| 1. Freeze | Executed 18:00 Friday; baseline 248,210 in-scope records |
| 2. Target backup | Verified restorable, reference BKP-2026-0814 |
| 3. Production migration | Completed 03:40 Saturday; reject log: 14 records (malformed metadata) |
| 4. Completeness | 248,196 of 248,210 migrated clean; 14 in reject log |
| 5. Accuracy | Per risk assessment RA-CSV-041: 100 percent verification of signed-record signature metadata (Criticality 5 class), zero defects; sampled verification of general document metadata, zero critical defects |
| 6. Reconciliation | 14 rejected records reviewed Saturday; 11 corrected and re-migrated clean; 3 dispositioned as approved exclusions (superseded drafts with no retention obligation), documented and QA-approved |
| 7. Go/no-go | QA and Migration Lead reviewed reconciliation report Sunday 14:00: go |
| 8. Release | Target released as system of record Monday 09:00; users notified; legacy system-of-record status ended |
| 9. Source state | Legacy repository kept read-only and recoverable, decommissioning not started |
| 10. Post-cutover check | Scheduled 2 weeks post go-live |
In this specimen the team classified every data class before cutover rather than deciding on the fly, froze the source with a clear timestamp, caught and dispositioned every rejected record rather than letting the count quietly fall short, and kept the source recoverable after go-live instead of treating cutover as the finish line. That sequence, disposition to freeze to verified cutover to a recorded go decision to a recoverable source, is exactly what a reviewer is expected to demonstrate.
Common inspection findings this plan prevents
- A migration executed with no documented model decision, so nobody can explain why a big-bang approach was chosen for a volume that would have benefited from phasing, or vice versa.
- A data class with no recorded disposition, discovered only when someone asks where a particular record type ended up.
- “Retain in legacy” used as a default with no named owner for the legacy system’s ongoing access control and support.
- A phased migration with no system-of-record rule, so the same data class exists differently in two systems during the overlap and nobody can say which one is correct.
- A cutover run with no rehearsed rollback, discovered to be untested only when reconciliation fails at 3 a.m. on cutover night.
- The source decommissioned or access removed immediately after a “successful” cutover, before the target had proven itself in real operational use.
- A go/no-go decision made informally, with no reconciliation report review and no recorded decision authority.
How to adapt this plan
- Set your document number, owner, and the linked risk assessment, mapping specification, and protocol numbers in the header.
- Decide and justify the migration model in section 3.1 before classifying any data, since the model changes how you sequence sections 7 through 10.
- Build the real data classification table in section 3.2 from your risk assessment’s data classes, and name an owner for every “retain in legacy” row.
- Name individuals, not just roles, in section 4, especially the go/no-go decision authority.
- Set a real freeze method and window in section 5 that your business can actually tolerate, and confirm it with the process owners before the plan is approved.
- Rehearse the rollback in section 9 during a dry run and reference that evidence directly; do not leave it as an assumption.
- Walk through the cutover runbook in section 10 during at least one full dry run before using it in production, and correct any step that did not work as written.
- Point the cross-references in sections 2, 6, and 12 to your real archive, decommissioning, and deviation procedures.
- Confirm every regulation in section 13 against the current published version before issue.