EDMS migration checklist

A pre-migration checklist for moving a technical-document archive off shared drives or a legacy EDMS without losing version integrity — the failure mode that turns a migration into a new source of audit findings instead of fixing the old one.

Before migration starts

• [ ] Every document's current-version status is confirmed in the source system before export — migrating an ambiguous "which one is current" problem just relocates it.
• [ ] Full revision history (not just the latest version) is included in the export scope, per document — a migration that keeps only the latest revision destroys traceability.
• [ ] Metadata (document type, discipline, retention class, approval history) is mapped field-by- field to the new system before the first file moves — not reconstructed afterward from filenames.
• [ ] A cutover scope decision is made explicitly: new and actively-revised documents move first; historical archive migrates on a scoped, module-by-module basis. A big-bang full-archive migration is not required to start controlling new documents.

During migration

• [ ] Each migrated document is checked against its source-system revision count — a document that arrives with fewer revisions than the source had is a migration defect, not an acceptable loss.
• [ ] File integrity (hash or checksum) is verified post-transfer for every document, not spot- checked on a sample.
• [ ] Access permissions and approval-chain assignments are migrated alongside the documents, not left to be manually re-created.

After migration

• [ ] A reconciliation report confirms document count, revision count, and metadata completeness match between source and destination before the source system is decommissioned.
• [ ] The source system stays in read-only, retrievable state for a defined retention window — it is not deleted immediately after cutover.
• [ ] New documents created after cutover are, from day one, under the new system's lifecycle and approval rules — no parallel "temporary" process continues on the old system.

Why this matters

Poor data quality is the single most-cited cause of failed migration projects — 84% of organizations report it affected a recent migration, and 23% report outright data loss during a system migration; 64% report missing the original budget and 46% report missing the schedule (Kanerika, 2025). Every checklist item above targets one of those specific failure points: metadata mapping and revision-count reconciliation address data loss; explicit cutover scoping addresses schedule risk; parallel-process elimination addresses the most common reason a "complete" migration quietly isn't.

Mechanism reference

The destination system's version integrity guarantees — strict versioning (ISO 15489-1 / MoReq2010), the four-state release lifecycle plus terminal obsolete, and metadata-matrix-driven retention — are what a migration needs to land into; see 02_Products_and_SaaS/e_edms.md.

Sources

• Kanerika, 2025 — 84% poor-data-quality impact, 23% data loss, 64%/46% budget/schedule miss rates in system migrations.
• Standards basis: ISO 15489-1, MoReq2010.