Scope and ownership
Outcome, source inventory, boundaries, decision rights, extraction constraints, and external dependencies.
Free editable CSV
40 evidence-first checks
Know what can break before the migration starts.
A software migration is not complete because rows imported or files copied. Use this checklist to expose the scope, data, relationships, security, integration, reconciliation, cutover, rollback, and recovery questions that should be answered before production depends on the result.
No email gate. Do not place protected records, credentials, personal data, case details, or other sensitive source content in the worksheet.
- Inventory before mappingKnow what exists before deciding what the target should contain.
- Preserve traceabilityKeep enough origin and mapping evidence to explain how a target value was produced.
- Reconcile relationshipsValidate files, links, history, and associations—not only record totals.
- Prove recoveryTest rollback and restore before the production cutover creates the need for them.
Readiness before execution
Treat migration as an evidence problem.
The worksheet is intentionally product-neutral. Use it during discovery, procurement, implementation planning, or pre-cutover review. A row marked “ready” should point to evidence that another reviewer can inspect.
- 01
Establish the baseline.
Inventory systems, records, files, metadata, relationships, users, interfaces, volumes, known defects, and ownership. Do not let the target data model define what you discover in the source.
- 02
Classify each check.
Mark each row Ready, Needs work, Blocked, or Not applicable. A not-applicable decision should still have a reason when the check addresses a material migration risk.
- 03
Attach evidence.
Use inventories, mapping workbooks, repeatable queries, test results, hash or integrity evidence, architecture diagrams, exception reports, approvals, and runbooks instead of unsupported status statements.
- 04
Assign blockers.
Give unresolved risks an owner, disposition, and decision deadline. A migration should not become the mechanism for discovering who had authority to accept data loss or access changes.
- 05
Re-run before cutover.
Readiness changes as mappings, source data, integrations, roles, and target configuration change. Review the evidence again against the actual production candidate.
40 migration checks
Eight areas that deserve an explicit answer.
The downloadable worksheet contains five checks in each area, along with an evidence prompt, suggested owner, status field, blocker/risk field, and notes column.
Data and metadata
Profiling, field mappings, identifiers, code values, normalization, exclusions, and source provenance.
Files and content
Attachments, hashes, corrupt or unsupported content, MIME and metadata preservation, malware handling, and exceptions.
Relationships and workflow
Links, history, ownership, roles, required-field exceptions, review states, and inherited workflow assumptions.
Security, privacy, and records
Data classification, staging controls, retention, temporary privileges, auditability, and safe evidence handling.
Integrations and identity
System-of-record ownership, interface failure behavior, SSO, service accounts, replay, reconciliation, and third-party dependencies.
Validation and acceptance
Repeatable counts, risk-based samples, relationship and file validation, exception disposition, and named sign-off authority.
Cutover, recovery, and operations
Rehearsal, rollback, backup/restore proof, hypercare, source retirement, exit obligations, and deletion evidence.
Reconciliation model
Do not let “the count matches” become acceptance.
Counts are useful, but they answer only one part of the migration question. Build acceptance around several independent views of the same result.
- 1
- Population. Compare source and target counts using repeatable queries and explain every expected difference.
- 2
- Values. Validate high-value fields, mappings, dates, code values, null behavior, transformations, and known edge cases.
- 3
- Relationships. Confirm parent-child links, references, attachments, history, users, and other associations survived with the right meaning.
- 4
- Content integrity. Where files are involved, verify byte counts, hashes or comparable integrity evidence, type handling, and exception disposition.
- 5
- Operational behavior. Test access, workflows, search, reporting, integrations, exports, downstream processing, and representative recovery scenarios.
Cutover boundary
Define the last safe decision point before you need it.
A production cutover should say when the source freezes, who authorizes each stage, what evidence must pass, what constitutes a rollback condition, and which systems can still be restored without losing newly created work.
- Freeze deliberately. Define how late source changes, queued work, and in-flight integrations are captured or reconciled.
- Gate the switch. Name the minimum evidence that must pass before users and integrations are released to the target.
- Preserve a recovery path. Prove database and file/object recovery together when both are required for a consistent system state.
- Watch the first days. Assign monitoring for failed jobs, access anomalies, integration failures, data defects, and user-reported exceptions.
Continue the decision chain
Use readiness evidence before choosing the migration approach.
Start with the migration checklist, then use the evaluation brief to capture the operating context and the software scorecard to compare target options through the same evidence model. If your scope includes a public portal, document archive, configurable workflow, or case-management replacement, the internal ZephCMS overview shows where that product may or may not fit.