A SharePoint-to-Azure migration succeeds or fails on decisions made before any script runs. Files transfer easily; metadata, permissions, versions, sharing links, workflows and retention controls do not, and each needs an explicit design choice.

Organizations accumulate years of documents in SharePoint Online. Some stays actively collaborative. Some becomes historical, compliance-driven or valuable mainly for analytics. For that second group, Azure Blob Storage or Azure Data Lake Storage Gen2 can be a scalable, lower-cost destination.

This guide gives you a practical reference architecture and a 12-step planning approach, with the Microsoft-documented limits and behaviours that shape each decision.

Key takeaways

• Classify before you copy. Sort content into retain, migrate, archive or dispose.

• Check native options first. Microsoft 365 Archive may meet a cost goal without leaving Microsoft 365.

• Match the destination to future use. Blob for archives, Data Lake Storage Gen2 for analytics, Azure Files for SMB/NFS apps.

• Use identity, not secrets. Microsoft Graph with least-privilege access (for example Sites.Selected) and managed identities.

• Respect throttling. Honour Retry-After, limit concurrency and decorate your traffic.

• Prove it moved. Validate with hashes (SharePoint exposes quickXorHash), not upload success codes.

• Plan tiers and lifecycle. Cool, Cold and Archive carry 30, 90 and 180-day minimum retention periods.

Step 1: Establish the reason for migrating

The target architecture follows the business objective, so name the objective first. Common drivers:

• Archiving inactive sites or historical project documents

• Reducing premium collaboration-storage consumption

• Creating a data lake for analytics, search or AI workloads

• Moving application-generated files to a service built for object storage

• Consolidating records under central cloud governance

• Retiring legacy sites after a merger, reorganization or completed programme

Azure Storage should not automatically replace SharePoint for active collaboration. If users still need co-authoring, approvals, familiar sharing, Microsoft 365 search or SharePoint-native workflows, keep that content in SharePoint, or move it to another SharePoint site.

Check the native option first. If the goal is mainly lower storage cost for inactive content, Microsoft 365 Archive moves inactive sites to a colder tier inside SharePoint, with the same security and compliance standards applied. Microsoft has also introduced file-level archive; check its current availability and pricing before deciding. Migrate to Azure Storage when you need object storage, analytics or integration, or must leave Microsoft 365.

Classify every piece of content

The first planning deliverable sorts content into four groups:

Step 2: Assess the source environment

A reliable design starts with an inventory. It is also a controlled opportunity for business owners to decide what moves and what stays.

The assessment should also flag unusually large files, duplicates and records needing manual review. These findings drive the schedule, the target data model and the validation effort.

Tip: for a tenant-wide inventory of sites, groups and files, consider Microsoft Graph Data Connect. It exports SharePoint and OneDrive metadata datasets to Azure Storage through Azure Synapse or Azure Data Factory. It reports on content; it does not copy file bodies.

Step 3: Choose the correct Azure destination

"Move SharePoint to Azure" is too broad to act on. The destination must match how the data will be used.

For archive or application-content scenarios, Blob Storage is often enough. Data Lake Storage Gen2 becomes the better choice when downstream services need a hierarchical namespace, analytics-oriented access or directory-level access control.

Step 4: Reference architecture

A scalable design separates discovery, transfer, storage and validation, so each can be reviewed, retried and scaled on its own.

Data flows top to bottom; identity and monitoring support the workers.

What each component does

Step 5: Design the content and metadata mapping

SharePoint concepts have no perfect one-to-one equivalent in Azure Storage. Agree a mapping document before you migrate.

Metadata versus index tags

Choose the carrier by how you will query the data, not by convenience.

Complex fields (people, lookups, taxonomy, large metadata sets) fit poorly in either. Keep them in a JSON manifest, Azure SQL or another catalog and key it by blob path.

Decide on version history early

Exporting every version can add significant migration time and storage. For some archives, the approved final version plus an audit manifest satisfies the requirement. For regulated records, that decision needs sign-off from records-management and legal stakeholders.

Step 6: Build identity and security into the design

Use identity-based authentication, not credentials embedded in scripts. Microsoft recommends Microsoft Entra ID with managed identities for Azure-hosted applications that access Blob Storage, because permissions are then managed through Azure RBAC and no account keys are distributed.

Permissions do not translate automatically

A user's right to open a document in SharePoint does not become an equivalent Azure permission. For archived data, simplify access to approved records or compliance groups. For operational data, the consuming application may need to enforce authorization. Document this mapping and have the data owner approve it before cutover.

Step 7: Select the migration pattern

For most enterprise scenarios, a phased approach with an incremental final pass gives the best balance of control and downtime.

For incremental passes, Microsoft Graph delta queries on a drive let you retrieve only items changed since the last sync, which suits the final reconciliation pass.

Step 8: Plan for throttling, scale and restartability

Throughput is limited by more than bandwidth. Plan around total file count (not only total size), average and maximum file size, API call volume, worker concurrency, Azure Storage request rates, retry behaviour and the migration window.

SharePoint Online uses throttling to protect service health. Microsoft's guidance for migration workers is clear:

Do not rely on IETF RateLimit headers from SharePoint Online; Microsoft states they are not returned or supported there.

Make every job idempotent

Re-running a job must not create duplicates or overwrite a newer item unless a deliberate rule says so. Store a deterministic destination path and the source hash in the manifest, and skip items already marked complete.

Handle large files deliberately

SharePoint Online supports very large files, so test the largest items in your inventory. Use ranged downloads and block-based uploads with retries, and stream data through the worker rather than buffering whole files in memory.

Step 9: Validate every migration wave

A file is not migrated because an upload returned success. Reconcile each wave against the source:

• Item counts, file sizes and folder-to-path mappings

• File hashes (see below)

• Required metadata and, if in scope, version counts

• Permission mappings

• Failed, skipped and excluded items

Hashing: use what SharePoint actually provides

Microsoft Graph returns a quickXorHash in the file.hashes facet of a driveItem, and it is the only hash guaranteed for both OneDrive for Business and personal OneDrive. It is a proprietary, non-cryptographic hash, so Azure Storage will not compute or compare it for you. Compute quickXorHash on the stream as you transfer it, compare it with the Graph value, and store it in the manifest. If you also need a standard hash, compute SHA-256 or MD5 yourself during the transfer and store it as a blob property or in the manifest.

Migration manifest

The manifest is your audit trail. At minimum, record:

Follow technical reconciliation with business-owner acceptance. Test a controlled sample that includes large files, deeply nested folders, sensitive content, files with custom metadata and documents with unique permissions.

Step 10: Define cutover and rollback before moving data

Agree the cutover sequence, and the rollback that goes with it, before the first production wave. Rollback must be practical, not theoretical: until acceptance is complete, SharePoint remains the authoritative source, so access can be restored while the issue is corrected.

A failed validation sends you back through a restored source and a repeat incremental pass. Retain the source for an agreed stabilization period, and archive or delete it only after formal approval.

Step 11: Apply governance, protection and lifecycle controls

Before migrating, confirm how the target will meet retention, privacy and recovery requirements. Retention labels, legal holds and SharePoint audit context do not follow a file into Azure automatically. Do not move regulated or legally held content until compliance stakeholders approve the destination and the evidence model.

Protection options to plan

• Blob soft delete and blob versioning for recovery from accidental deletion or overwrite

• Immutable storage (WORM policies) for approved records

• Redundancy that matches your recovery objectives (LRS, ZRS, GRS or GZRS)

• Diagnostic logging, alerting and periodic access reviews

• Documented approval before any deletion

Choose access tiers deliberately

Moving or deleting a blob before its minimum retention period triggers an early-deletion charge. Archived blobs cannot be read until you rehydrate them to an online tier, and rehydration cannot be done through lifecycle policies. Microsoft's access tier documentation also lists redundancy limits for the Archive tier (it is not available on ZRS, GZRS or RA-GZRS accounts), so confirm your redundancy choice before you design around Archive.

Lifecycle rules follow policy, they do not replace it

Lifecycle management policies can transition eligible blobs to cooler tiers or delete them based on rules you define. Derive those rules from your retention schedule. A common pattern is to keep content in Hot during migration and validation, then move it to Cool, Cold or Archive after an approved stabilisation period.

Step 12: Estimate cost across the full lifecycle

Storage capacity is only one line of the bill. Estimate every cost driver with the Azure pricing calculator using your real inventory, not averages.

Archive saves the most on storage but adds retrieval delay and cost, so confirm the business accepts both before you commit.

Planning deliverables checklist

Before implementation begins, the project should have produced:

• [ ] Business scope and success criteria

• [ ] SharePoint content inventory

• [ ] Data-classification and disposition decisions

• [ ] Target architecture diagram

• [ ] Content and metadata mapping

• [ ] Identity, permission and network design

• [ ] Migration wave plan

• [ ] Performance and throttling model

• [ ] Validation and acceptance plan

• [ ] Cutover and rollback procedure

• [ ] Governance and retention design

• [ ] Cost estimate

Conclusion

A successful SharePoint-to-Azure migration begins with classification and architecture, not code. The central question is not "How do we copy the files?" but "Which SharePoint capabilities must we retain, replace, redesign or intentionally retire?"

Answer that early and Azure Blob Storage or Data Lake Storage Gen2 becomes a secure, scalable and cost-controlled home for the right content. The result is easier to validate, easier to operate and far less likely to become an ungoverned archive.

Your next step: build a pilot that inventories one approved library, migrates a representative content set, preserves the agreed metadata and produces a full reconciliation report before you scale to production.

References

• Avoid getting throttled or blocked in SharePoint Online

• Working with files in Microsoft Graph

• Hashes resource type (quickXorHash)

• Access tiers for blob data

• Manage and find Azure Blob data with blob index tags

• Azure Blob Storage lifecycle management overview

• Authorize access to blobs using Microsoft Entra ID

• Microsoft 365 Archive overview

This article presents a general reference architecture. Adapt production migrations to your organizational, regulatory, licensing and workload requirements, and confirm limits and pricing against current Microsoft documentation.