SMART Migration – SharePoint Offloading to Azure Blob Storage
Frequently Asked Questions
—-
Should the configuration of the Offload source and destination be handled by the IT department?
Yes. The configuration of the offload job (source SharePoint environment, target Azure Blob Storage account, selection criteria for which files to offload) is an IT administration task. This is comparable to any storage management operation — IT defines the policies, selects the content scope, and manages the Azure Blob Storage infrastructure. End users are not involved in the configuration.
Important: It is strongly advised to only offload files that are rarely accessed, due to the overhead of a restore operation. Files that are frequently needed should not be offloaded. Typical candidates are old project files, archived documents, or historical records that must be retained but are seldom opened.
Would end users only see the file structure while maintaining an interface similar to Teams and SharePoint?
Exactly. This is one of the key differentiators of the solution. After offloading, the full document library items remain in SharePoint/Teams with all their metadata intact — the only thing removed is the binary file content (the actual file data). From the end user’s perspective, they continue to use Teams and SharePoint as they always have. They see the same file names, folders, metadata columns, and document library structure. The footprint of each “stub” item is less than 1KB while the binary content is stored in Azure Blob Storage at ~95–97% lower cost compared to SharePoint Online storage pricing.
Since the complete document library item is retained, all files remain fully findable — by file name, folder structure, and all metadata columns. Users can search and filter exactly as before. The only difference is that opening a file requires a restore step.
When a user needs to restore some files, do they have to request it from IT so that IT creates another job?
In the standard setup, yes — a restore operation is a job that IT runs through SMART Migration. IT defines which files to restore and where (either to the original location or an alternative SharePoint site or file share). This is a fast and straightforward operation, not a complex project. However, there is also a self-service option — see the next question.
Is there no possibility to have a “Restore file” option directly in the file menu?
Yes, there is a self-service option. When files are offloaded, each file is transformed into a .url file — for example, myfile.docx becomes myfile.docx.url. This URL points to a PowerApp with arguments that pre-configure the necessary columns to automatically create a restore job. The PowerApp source code is provided so the customer can customize it to fit their organization’s needs and workflows.
That said, it is advised that the restore process remains an administrative task within the organization, to maintain proper governance and control over storage management.
How is the end-user interface different from other tools?
The key differentiator is that the end-user experience through Teams and SharePoint is fully preserved. Unlike solutions that move files to a completely separate archive or cold storage tier that users can’t see, SMART Migration keeps the document library structure and all metadata visible in the familiar Teams/SharePoint interface. Users continue performing the same operations — browsing, searching, filtering by metadata — without realizing that the binary content has been offloaded. Since all file names, folder structures, and metadata columns are retained, findability is identical to before the offload. This transparent approach dramatically reduces change management overhead and end-user resistance.
If a customer purchases MigrateDMS to offload files, do they need to pay a subscription forever?
No. A paid license is only required for the offloading operation itself. Restore is always free — regardless of when or how often files need to be restored.
Furthermore, the way the offload stores data in Azure Blob Storage is fully transparent, meaning the customer is never locked in. A restore can also be built by the customer’s own developers or by third parties, since there is no proprietary black-box format involved.