SharePoint Migration: Preserving Metadata and Version History During File Share Cutover

Moving content from a legacy file share into SharePoint Online or Microsoft 365 is rarely as simple as copying folders into a document library. The structure that matters most to a records team often lives outside the files themselves, in the modified dates, the author attributes, the folder taxonomy and the version chains that document how a record changed over time. When a migration drops this context, the files may open correctly yet lose the evidential value that underpins retention schedules and discovery obligations.

This is a particular risk in government, aged care and enterprise environments where provenance is not optional. A document that arrives in SharePoint with a creation date of the migration day, no version history and no classification is, for records purposes, a different artefact to the one that left the file share. Understanding exactly what a copy job preserves and what it silently discards is the first step towards a defensible cutover.

Why naive copy jobs silently drop context

A straightforward drag and drop, a mapped drive copy or a tool such as Robocopy will move the file bytes faithfully, but it treats each file as a single current object. The upload process stamps the destination with new system metadata, so the created and modified timestamps reflect the migration rather than the document's real history. Authorship is attributed to the migrating account, and any earlier revisions held by the source system are flattened into one version, erasing the trail that shows who changed what and when.

Managed metadata and content types present a second, quieter failure. File shares have no concept of a term store or a content type, so a plain copy cannot populate those fields because there is nothing in the source to map from. If the target library expects documents to carry a record category, a security classification or a function and activity term, those columns arrive empty, and the automated retention and disposal rules that depend on them never trigger. The content looks migrated, but the governance layer that makes it discoverable and compliant is missing.

Establishing content types and managed metadata before cutover

The remedy begins well before any files move, by designing the destination information architecture first. Define the content types the records programme requires, publish them through the content type hub where multiple sites will reuse them, and build out the managed metadata term store so that classification values exist and are governed centrally. This work establishes the vocabulary into which source content will be mapped, and it prevents the common situation where libraries fill up faster than the taxonomy that is meant to describe them.

With the target in place, the migration can carry a mapping layer that assigns values during transfer rather than afterwards. The SharePoint Migration Tool and Migration Manager both accept a mapping file that lets you direct source paths to specific destination libraries, apply content types, and set column values including managed metadata terms. Deriving those values from the source folder structure, naming conventions or an accompanying index means documents land already classified, so retention labels and disposal rules apply from the first day rather than waiting on a manual reclassification exercise that rarely completes.

Preserving version history and authorship

Retaining the version chain is essential wherever a document's history forms part of the record. Microsoft's migration tooling can transfer multiple versions of a file so that each revision appears in SharePoint's version history with its original author and timestamp, provided the source system actually exposes those versions and the destination library has versioning enabled. Confirm that major versioning, and minor versioning where it is used, is configured on the target before cutover, because versions that arrive without a library setting to receive them are simply collapsed.

Authorship and dates deserve the same attention, since a record that attributes every change to a service account offers little evidential weight. Migration tools that honour the source created, modified, created by and modified by values will reproduce a faithful timeline, but this behaviour depends on correct configuration and on permissions to write those fields. Plan a representative pilot that migrates a sample set, then inspect the version history, the author columns and the timestamps against the source to verify that the chain survived intact before committing the full volume.

Validation and records compliance

Validation is where a government records team earns confidence that the migration is defensible. Build a reconciliation process that compares source and destination counts, checks a sample of files for correct version history, confirms that content types and managed metadata columns are populated, and tests that retention labels resolve as expected. Capturing migration logs and any error or skipped item reports provides an audit trail that demonstrates due diligence should the integrity of the records be questioned later.

Finally, align the technical design with the obligations that govern the content. Retention and disposal authorities, discovery requirements and sector record keeping standards all assume that metadata and history remain intact, so the migration plan should trace each required attribute back to the rule it supports. Treating the cutover as a records project with technical execution, rather than a file copy with a compliance afterthought, is what keeps the migrated content usable, discoverable and trustworthy.

References

• SharePoint Migration Tool overview (Microsoft Learn)
• Migration Manager (Microsoft Learn)
• Records management practices (National Archives of Australia)