EDMS Migration Checklist

An EDMS migration passes when the agreed records, context and access work in the accepted destination, with every required exception resolved or formally dispositioned under the approved plan. A successful import job or matching file total is only part of that evidence.

Use this checklist before approving a migration wave or final cutover. It covers record acceptance rather than the full implementation project or a specific export tool. Assyro checked the primary sources on October 6, 2026. The sample below is a documentary exercise, not a completed migration between commercial products.

Set the scope and result rules

Record the source and target systems, configurations, migration wave, extraction cutoff and record owner. Define what moves into the active target, what remains in an accepted archive and what is excluded with justification. Identify the applicable record requirements and intended use.

For every checklist row, retain result, evidence location, owner and decision date. Use these meanings:

• Pass: the applicable acceptance criterion has supporting evidence for this wave.
• Fail: observed evidence contradicts the criterion; correction and retest are required.
• Unknown: evidence, scope or ownership is missing; the row has not passed.
• Not applicable: a documented reason and authorized reviewer establish that the check does not apply.

A blank is unknown. Mandatory failed or unknown rows prevent cutover. Repeat checks by field, record family or role when their results differ; do not hide a failed subset inside an overall pass. An exception cannot waive an applicable legal obligation; the record owner and designated quality or system approver must accept any permitted alternative against the approved requirements.

Checklist A: define the population before extraction

For EU GMP computerized systems within its scope, Annex 11 section 4.8 calls for migration checks addressing preservation of data value and meaning. The Commission's current index lists the January 2011 revision. That supports evaluating record context, not just whether a file opens. EudraLex index, Annex 11, revision 1.

These checklist rows are proposed acceptance controls, not a universal statutory package. Decide the extent of verification from the actual record risks and intended use. Explain the basis for sampling where used; a successful sample does not excuse a known missing required record.

Checklist B: preserve identity, meaning and history

Do not infer equivalence from similar labels. A source “approved” state may mean signed but not effective, while the target's similarly named state permits use. Write the mapping in terms of behavior and test the affected access or workflow.

A hash comparison can support a byte-integrity check for an unchanged file. It does not prove the correct source was selected, the metadata is meaningful or the target permission is appropriate. A planned format conversion may change the bytes and needs its own acceptance method.

Where Part 11 applies to a closed system, 21 CFR 11.10 includes controls for copies, retrieval, access and audit trails. Evaluate those requirements with FDA's scope and application guidance and the relevant underlying record rules; do not assume every file has the same obligations. 21 CFR 11.10, FDA Part 11 guidance.

Checklist C: test access and reconcile exceptions

An administrator's successful search is not an access test for ordinary users. Test a restricted reader and an unauthorized role separately. Also distinguish the original historical author from the account that performed the import; rewriting every past action as the migration account destroys that distinction.

An accepted archive can be part of the design, but it must be a usable, governed destination. Identify its access route, owner, retrieval method and required availability. “Keep the old server somewhere” does not resolve an untested retention dependency.

Use this migration manifest

Keep one row per counted object, with relationships back to its logical document. Record the run ID and scope baseline in the manifest header. The table is a suggested working schema; adapt it without losing the ability to reconcile exact objects.

Use stable IDs as the reconciliation key. Filenames and titles can help a reviewer but may be duplicated or changed. Keep authoritative metadata in the controlled source or accepted target; the manifest should reference it rather than create a competing editable master.

Worked example: matching totals can still hide loss

Consider a fictional four-document migration wave. The agreed version inventory is D10/v1–v2, D20/v1–v3, D30/v1 and D40/v1–v2: eight version objects. It also contains three attachments, A1, A2 and A3, and four separately counted history packages. A3 belongs to D40/v2.

Do not add these figures into one ambiguous “document count.” They represent different units and relationships.

The migration lead reruns the attachment import. It now reports three successful rows, but the observed IDs are A1, A2 and A2. The total matches while A3 is still missing and A2 is duplicated. The attachment check remains failed.

After correction, the target contains A1, A2 and A3, and A3 opens from the correct D40/v2 relationship. That resolves the attachment exception. It does not automatically close the other checklist rows.

Populate the decision log as follows:

The wave is not ready while the required access test remains unknown. After that test passes and the remaining required checks are accepted, the authorized approver can release this wave. A later success does not erase the failed run's history.

Checklist D: control the delta and cutover

Rollback is not merely turning the old system back on. If users have created records in the target, define how those records are preserved and reconciled before changing authority again. Rehearse the agreed recovery approach without destructive, unplanned production changes.

Extend the fictional wave: after baseline extraction, D40/v2 is withdrawn and one reader loses access. No document or attachment count changes. A final run that checks counts alone misses both changes. The process owner verifies D40/v2's intended retained-but-withdrawn behavior, and the access owner repeats retrieval with the revoked account. Separately, if D50/v1 was created in the target after cutover, record its owner and recovery destination before any rollback. An unknown destination blocks the proposed rollback decision; switching the old server on cannot prove D50 was preserved.

Once all mandatory checks pass or have an authorized, requirement-satisfying disposition, record the exact accepted wave, manifest revision, exceptions and cutover decision. Keep failed and corrected run evidence accessible. Do not delete the source merely because the import service returned a success message.

For the wider evidence plan, see our computerized system validation guide. For lifecycle and effective-state questions, use the QMS document control guide.

If you are evaluating a regulatory-document handoff involving Assyro, bring a representative manifest and exception to the discussion. Confirm the actual destination capabilities and responsibilities. This checklist can structure that review; completing it does not itself certify a system or establish regulatory acceptance.