This page explains how version history is handled by Squirrel when files are archived and later restored back into SharePoint.

It is intended for customer administrators who need to understand how historical versions, authorship, and timestamps behave during the archive and rehydration lifecycle.

When Squirrel archives a file, the file and its available SharePoint versions are stored securely in Azure Blob Storage. When a user restores a file via a stub, Squirrel rebuilds the version chain in SharePoint so that the file can continue to function as a normal SharePoint document.

The restore process is designed to preserve version history and associated metadata as closely as possible, while operating within the constraints of Microsoft 365 and SharePoint’s versioning model.

During a restore, Squirrel performs the following high-level actions related to versions:

• Archived versions are retrieved from Azure Blob Storage.
• SharePoint version entries are recreated.
• File content is written back into SharePoint.
• Version-level metadata such as author and modified timestamps are applied where supported.

The objective is to reconstruct the version chain so that historical changes remain visible and traceable inside SharePoint.

Version history in SharePoint is metadata stamped onto each version of a file.

During restore, Squirrel attempts to apply:

• Version authors
• Modified timestamps
• Version ordering
• File-level metadata

Where the original user account exists in Microsoft Entra ID and can be resolved, SharePoint will normally display the original author information. If SharePoint cannot resolve the account, it may automatically fall back to a system identity.

Because this behaviour is ultimately controlled by Microsoft 365, exact stamping results may vary in some environments.

In addition to version history, Squirrel is designed to capture and restore SharePoint file metadata where supported by the platform.

This includes both standard and custom library columns. During archive and restore, Squirrel attempts to preserve values for commonly used SharePoint field types, including:

• Single line of text
• Multiple lines of text
• Choice
• Number
• Date and Time
• Person or Group
• Currency

Because SharePoint allows a wide variety of custom column types and configurations, not all field types are technically supported for full fidelity capture and restore. Certain complex or special-purpose fields (for example images, maps, or some highly customized field types) may not be fully captured or rehydrated.

The objective of the Squirrel metadata process is to preserve business-relevant metadata wherever technically possible, while operating within Microsoft 365 and SharePoint platform constraints.

SharePoint supports both major and minor versions. Minor versions are often hidden in the user interface, but they still exist internally.

If the most recent change to a file before archiving was a minor version, the following can occur during restore:

• SharePoint rebuilds the historical version chain.
• The previously hidden final minor version becomes visible.
• SharePoint writes the restored file back as a new current version on top.

This results in:

• A new visible top version representing the restored file.
• The previously hidden minor version appearing directly below it.

This can make it look as though version numbers or authors have shifted, when in fact the historical change already existed and has simply become visible.

The underlying history is not rewritten. The restore process exposes the previously hidden version and adds a new current version above it.

After a restore, administrators may observe:

• A newly created top version representing the restored file.
• Older versions reconstructed beneath it.
• Previously hidden minor versions becoming visible.
• Version timestamps and authors populated where supported by SharePoint.

This is normal SharePoint behaviour when a file is programmatically rebuilt and does not indicate loss of history.

Version information is applied as SharePoint metadata on each restored version.

As a result:

• Files and versions remain part of the SharePoint content store.
• Author and modified fields remain available where applied.
• Content remains discoverable using Microsoft Purview eDiscovery tools, subject to Microsoft platform capabilities.

The restore process is designed so that archived content can be returned to SharePoint and continue participating in standard Microsoft 365 governance, compliance, and discovery workflows.

If you require assistance validating restored version history, or need support for compliance testing scenarios, contact support@smikar.com.