A document migration should move only content that has a defined business purpose, authoritative destination, required metadata, correct access and tested lifecycle. Copying every file reproduces duplicates, obsolete versions and inherited permission risk.
Inventory first, decide disposition by content class, rehearse with control totals and preserve rollback. The migration is accepted when users can find and trust the right document and administrators can explain what remained behind.
Define purpose and authority
State which business services and document classes the target will support. Name authoritative repositories and owners. Set the migration boundary by content, team, date and lifecycle—not merely by server folder.
Record legal, contractual and policy constraints with specialist review where needed. Migration must not become an informal disposal decision.
Build the inventory
Collect path, size, type, dates, owner, access, duplicate signal, metadata, version, link and activity. Include personal drives, collaboration spaces, email archives and specialist systems only where in scope.
Profile anomalies: ownerless folders, broad links, unsupported formats, encrypted files and names too long for the target.
Create the disposition map
| Disposition | Use when | Required evidence |
|---|---|---|
| Migrate | active/required and target supports lifecycle | owner, class, metadata and access |
| Transform | format or metadata must change | mapping and quality test |
| Archive | retained but not active | retrieval and retention owner |
| Temporary retain | decision or dependency remains | expiry and accountable review |
| Dispose | approved policy permits deletion | authorisation and retained record |
Resolve duplicates and authority
Use hashes, names, metadata and business review to identify exact and near duplicates. Decide the authoritative version from lifecycle and owner, not newest timestamp alone.
Preserve relationships and explain consolidated copies. Do not automatically delete potential records because content appears similar.
Design metadata
Map only metadata that supports retrieval, lifecycle, access or integration. Define values, controlled lists, defaults and who can correct them. Separate source preservation from target enrichment.
Test that ordinary users can classify content at the correct moment. Excessive mandatory fields drive work outside the system.
Map permissions
Translate people, groups, inherited access, external links and exceptions. Prefer role or team groups over recreating historical individual permissions. Identify sensitive content for separate review.
Test leavers, changed teams, guests and support administrators. File accessibility is not acceptance if access is too broad.
Handle versions and links
Decide whether to migrate all versions, selected milestones or current plus audit. Preserve approved/effective state. Inventory links from documents, intranet, workflows and business systems.
Create a redirect or link-repair plan where feasible and publish the cutover rule. Broken references can make correctly migrated content unusable.
Run repeated rehearsals
Use representative content classes and difficult files. Record duration, throughput, failures, warnings and target behavior. Fix mapping and rerun from a clean state.
Do not treat a successful upload count as acceptance. Users must search, open, edit, approve, share and retain according to the target process.
Reconcile with control totals
Compare count and bytes by source, class, disposition and result. Track migrated, rejected, skipped, duplicate, transformed and pending. Sample content, metadata, versions and access.
Investigate every unexplained difference. Retain immutable logs and checksums where risk warrants it.
Plan cutover and rollback
Define freeze or delta, final extraction, user communication, support, source read-only state and authority switch. Set success and rollback thresholds.
Rollback must account for documents created or changed after cutover. Keep source and target changes reconciled during the decision window.
Prepare users and support
Explain which repository becomes authoritative, how folders or metadata change, where old links go and how to report a missing or restricted item. Train through real retrieval and collaboration tasks rather than a product tour.
Give support the disposition map, error codes, access escalation and rollback boundary. Track repeated questions as evidence of unclear design.
Handle difficult file types
Test large files, macros, embedded links, scanned documents, signatures, email messages, archives, unsupported formats and encrypted content. Decide transform, preserve with viewer, archive or exclude. Record any lost behavior.
Virus scan and validate content without changing evidential meaning. Keep conversion source and result linked where required.
Protect active collaboration
Identify documents being edited, reviewed or approved during the migration window. Assign an owner and controlled delta path. Avoid copying a draft twice and allowing both versions to continue.
For external workspaces, coordinate participant access and notification. Do not expose target paths before permission acceptance.
Use acceptance by content class
Let owners test representative retrieval, edit, approval, sharing, retention and integration for each class. Record pass, exception and residual risk. A global migration percentage cannot prove that a critical contract or policy workflow works.
Close a class only after its authoritative path, access and lifecycle are accepted.
Stabilise and close
Monitor failed search, access requests, missing links, support and new classification. Resolve exceptions, then approve archive or disposal of sources separately.
Transfer ownership, mapping, logs, residual risk and review dates. The project closes when document authority and operating lifecycle are clear—not when copying stops.
Run a final sample with users outside the project team; familiarity with the migration can hide retrieval and access problems.