SMART Offload — Frequently Asked Questions
Section titled “SMART Offload — Frequently Asked Questions”SHAREPOINT OFFLOAD TO AZURE BLOB STORAGE
Reduce SharePoint storage consumption while keeping document proxies, metadata and library structure visible in Teams and SharePoint. These questions explain configuration, the user experience, restore options and licensing.
Configuration and content selection
Section titled “Configuration and content selection”Should IT configure the offload source and destination?
Yes. Configuring the source SharePoint environment, destination Azure Blob Storage account and content-selection criteria is an IT administration task. IT manages the infrastructure, defines the offload policies and controls execution. End users do not need to configure the jobs.
For full-file offload, select content that is rarely accessed, such as completed project documents and inactive records that are eligible for offload. Frequently used files should generally remain active in SharePoint because accessing offloaded binary content requires restoration.
Alternatively, retain the current version in SharePoint and offload only historical versions.
The end-user experience
Section titled “The end-user experience”Do users continue working through Teams and SharePoint?
Yes. Offloaded items remain visible in the existing document library through small proxies. Users can browse the familiar folders and review the retained metadata columns in Teams and SharePoint.
For full-file offload, the original binary content is stored in Azure Blob Storage. A document such as myfile.docx is represented by a proxy named myfile.docx.url. Opening the proxy starts the configured restore-request process rather than opening the original document directly.
The remaining SharePoint storage footprint depends on metadata, version count and whether the current binary is retained.
Can users still find offloaded documents?
Users retain the folder structure, visible proxy names and metadata for browsing and filtering. Search can use retained information where the relevant fields are indexed and searchable.
Metadata-based findability and full-text content search are different. Binary content held only in Azure Blob Storage is not automatically available to SharePoint content indexing. If the current document version remains in SharePoint, that active content remains available for normal indexing.
Restoring files
Section titled “Restoring files”Does a user need to ask IT to restore files?
In the standard setup, yes. IT runs a restore job through SMART Migration, selecting the content and its destination. Files can be restored to their original location, another supported SharePoint destination or a file share.
The restore configuration is straightforward. Completion time depends on the volume, infrastructure and Azure storage tier. Archive-tier content requires rehydration before retrieval.
Is a self-service restore option available?
Yes. The .url proxy can point to a Power App and pass arguments that prepopulate the information required to create a restore job.
myfile.docx → myfile.docx.url → Power App → Restore job
The Power App source is provided so the customer can adapt the interface and workflow to its requirements. This is a configurable restore-request approach; it is not automatically a native “Restore file” command in the SharePoint file menu.
IT should retain administrative control of restore permissions, destination selection and execution. User requests can be incorporated into the organisation’s approval process.
How the approach supports adoption
Section titled “How the approach supports adoption”What is different about the user interface?
SMART Offload retains visible document proxies and metadata in the existing Teams and SharePoint environment. Users can locate content through familiar libraries and folders instead of relying solely on a separate archive interface.
This continuity can reduce change-management effort. Users still need to understand the proxy files, the restore-request process and the difference between metadata search and searching the offloaded document content.
Licensing and access to stored content
Section titled “Licensing and access to stored content”Must the customer maintain a paid subscription indefinitely?
No. A paid SMART Offload licence is required to perform offload operations. Restore functionality is free of MigrateDMS licence charges, regardless of when or how often content is restored.
A continuing paid licence is required if the customer wants to keep offloading newly eligible files or historical versions. Azure storage, retrieval, transactions and data-transfer charges remain separate from the MigrateDMS licence.
Is the offloaded content locked into a proprietary format?
The Azure Blob Storage layout is transparent and does not rely on a proprietary black-box storage format. The customer’s developers or a third party can build an alternative retrieval or restore process using the stored content and associated references.
Recreating the complete SharePoint item, metadata and version history requires the relevant mapping information and an appropriately implemented restore workflow.
Important limitations
Section titled “Important limitations”Sensitivity labels, retention labels and Purview encryption
The SMART Offload workflow described here does not support preservation of sensitivity labels or retention labels during offload. Forcing these files through the process can result in label loss. Files encrypted using Microsoft Purview are also outside the supported scope of this workflow.
Exclude affected content from offload and resolve its treatment before execution. These are limitations of the described SMART Offload workflow, not a general statement about Azure Blob Storage.
Keep content visible. Control offload centrally. Restore files when they are needed.
See also