SharePoint Migration Services in 2026: What Your Provider Should Actually Deliver

SharePoint Migration Services in 2026: What Your Provider Should Actually Deliver

Short answer: an enterprise SharePoint migration provider should hand you a working hub-and-spoke information architecture, a tested permission model that survives an audit, automated metadata mapping for everything legal cares about, and a real change-management plan — not a list of file shares ported over with permissions reset to "Everyone Read."

If you've been burned on a SharePoint migration before, this guide is for you. We've led thousands of SharePoint implementations across 29 years and have inherited a lot of cleanup work from migrations that someone else did first. The pattern is consistent: the technical migration completed on time, the business never adopted the new environment, and three years later the old file shares are still there because nobody trusts the new SharePoint.

What SharePoint migration services actually need to cover

The market term "SharePoint migration services" is used to describe at least four very different scopes. Get clear on which one your provider is selling before you sign anything.

Lift-and-shift only. Files copy from source to SharePoint Online with permissions translated where possible. This is the cheapest option and almost always fails to drive adoption.

Information architecture redesign + migration. A new hub-and-spoke architecture is designed first, then content migrates into the new structure with metadata applied. This is what enterprise buyers should expect.

Migration + governance + adoption. All of the above plus retention labels, sensitivity labels, DLP policies, change management, and a 90-day post-go-live adoption push. This is what we deliver as part of SharePoint consulting.

Migration as part of an M365 modernization. SharePoint migration is one workstream inside a larger Microsoft 365 program that also covers Teams, OneDrive, Exchange, Intune, and Purview. This is correct for any organization with 5,000+ users.

The four migration mistakes that kill adoption

1. Permissions reset to broken legacy state. The source file share had permission drift over a decade. Lifting it as-is means the new SharePoint inherits all the same problems plus the surface area to make them worse. Real migrations include a permissions audit and remediation in the destination.

2. Metadata not applied at migration time. "We'll add metadata after we go live" is a tell that you'll never have metadata. The right time to classify documents is during the migration, when you have leverage over the migration tool. Once content is live, retroactive classification is a project nobody wants to fund.

3. The hub-and-spoke architecture wasn't designed first. Lifting a flat file share into a flat SharePoint site is a guaranteed failure. The new structure needs to support hub navigation, search, and information lifecycle rules — none of which can be designed after the migration.

4. Change management treated as an afterthought. Power users get one training session, executives get a memo, the rest of the organization gets nothing. Six months later, the file shares are still active because the change never landed.

What a good migration timeline looks like

A 5,000-user enterprise SharePoint migration with proper governance:

• Week 1-2: Discovery — content inventory, permission audit, retention requirements, integration map
• Week 3-4: Information architecture design — hubs, sites, navigation, metadata schema
• Week 5-6: Pilot migration — one business unit, full lifecycle including permissions, labels, DLP
• Week 7-10: Wave 1 production migration with executive change-management push
• Week 11-14: Waves 2-4 production migrations
• Week 15-16: Cutover, source decommission, post-go-live tuning
• Week 17-26: 90-day adoption push — power user network, training, governance enforcement

Anything shorter than 12 weeks for a 5,000-user environment is either skipping change management or using a tool to do the work without architectural design. Both lead to the same outcome.

Tooling: what providers actually use

The migration tooling matters less than people think, but the choice signals seriousness:

• SharePoint Migration Tool (SPMT): Microsoft's free tool. Adequate for simple file-share-to-SharePoint moves. Not adequate for permission translation at scale.
• ShareGate: the industry standard for enterprise SharePoint migration. Handles permissions, metadata, version history, and IA mapping. Most reputable providers use it.
• Quest On Demand Migration: alternative to ShareGate, stronger for tenant-to-tenant.
• Tzunami: specialized for legacy ECM (Documentum, Livelink, FileNet) to SharePoint.
• Custom PowerShell + Microsoft Graph: the right answer for very large or unusual migrations where commercial tools hit limits.

A provider that only uses SPMT for everything is signaling small-engagement experience. A provider that uses three or four tools depending on source signals enterprise readiness.

The compliance ribbon: HIPAA, SOC 2, FINRA, FedRAMP

Migration scope changes dramatically in regulated environments. The provider should be able to describe:

• The Business Associate Agreement scope for HIPAA-bound content
• The retention schedule mapping for FINRA 17a-4 (write-once-read-many) records
• The Designated Record Set boundaries if you're a HIPAA covered entity
• The CUI handling for FedRAMP / CMMC environments
• The audit-log review process post-migration

If they can't, they haven't migrated regulated content before. Don't be the engagement they learn on.

What month 13 looks like

A successful SharePoint migration produces this state at month 13:

• Source file shares fully decommissioned (not "still up for reference")
• Power user network active and self-sustaining
• Executive dashboards on SharePoint analytics showing adoption metrics
• Retention labels expiring content automatically per schedule
• DLP policies in enforce mode (not audit mode)
• A documented governance steering committee meeting at least quarterly
• Search relevance tuned and monitored monthly

If your provider can't describe this end state in concrete terms, they're selling a project, not a platform.

Frequently asked questions

How long does a SharePoint migration take?
Small (under 1,000 users): 6-8 weeks. Mid-market (1,000-5,000): 12-16 weeks including governance. Enterprise (5,000-50,000): 6-9 months for full lifecycle including 90-day post-go-live adoption.

How much does SharePoint migration cost?
Lift-and-shift only, no governance: $50K-$150K for mid-market. Full lifecycle with IA design, governance, and adoption: $200K-$750K depending on scale. Enterprise migrations with multiple legacy ECM sources can exceed $1M.

Can SharePoint migration be done without downtime?
Yes, with delta migration tooling. The cutover requires a short freeze (typically 24-48 hours over a weekend), but the bulk of content can move while the source remains in production.

What about Lotus Notes / IBM Domino migrations to SharePoint?
Possible but complex. Plan for 18-24 months for full Notes-to-M365 migration of a 10,000-user environment. The application portfolio analysis is the long pole — most Notes shops have 200-500 custom databases that need triage.

Do SharePoint migrations cover Microsoft Copilot readiness?
They should. Copilot inherits all of your SharePoint permission problems. A migration that doesn't fix permissions and apply sensitivity labels at the same time will leave you with a tenant that fails Copilot readiness.

Talk to EPC Group

We've led thousands of SharePoint implementations across 29 years, including some of the largest tenant-to-tenant migrations in regulated industries. If you want a no-cost discovery call with a senior architect who can give you a fixed price on a pilot wave inside two weeks, contact EPC Group.