SharePoint migration: Why one-to-one migration is rarely the right answer

The biggest risk in a SharePoint migration is not data loss. It is the successful migration of years of bad decisions.

If your migration plan is reduced to copy -> paste -> go live, you carry yesterday’s problems into tomorrow’s workplace. We are currently supporting one of Austria’s largest SharePoint migrations: more than 25 terabytes, over 130 major projects, millions of documents and versions from SharePoint 2016 on-premises to SharePoint Online. The most important decision was made right at the beginning: this will not be a one-to-one migration.

In this opening article of our enterprise SharePoint migration series, we explain when lift-and-shift works, when it fails, and which business and technical criteria should drive the decision.

When a one-to-one migration is perfectly fine

First of all: one-to-one migration is not a dirty word. It is the right choice when:

• the information architecture is current and accepted and users can find what they need,
• permissions are traceable and match the current organization,
• the used features exist one-to-one in SharePoint Online with no farm solutions or server-side customizations,
• the data volume and structural size stay within SharePoint Online limits.

In that case: use standard tools, migrate, done. Any additional redesign adds project risk without benefit.

When lift-and-shift fails from a business perspective

In grown on-premises environments, we repeatedly see the same patterns:

1. Every project has its own universe. Over the years, each major project creates its own site collections, content types, terminology and filing logic. What was pragmatic at the time becomes uncontrolled growth that nobody can search, govern or evaluate consistently.

2. Metadata nobody maintains anymore. Fields introduced ten years ago are half-filled, inconsistently named or mean different things in project A and project B. A one-to-one migration preserves that state, including the search results it creates.

3. Permission archaeology. Unique permissions on folders and items, orphaned groups, users who left the company years ago. Migrating that as-is means migrating an audit problem.

4. Document classes without a shared vocabulary. If the same document type appears under 15 different labels across 130 projects, the migration is the only realistic moment when consolidation is still affordable. After that, nobody will touch these data estates again.

The business lesson is simple: a migration is the best, and often last, moment to repair your information architecture. Not because technology demands it, but because budget, attention and management support exist at exactly that moment.

When lift-and-shift fails from a technical perspective

Even more often overlooked: there are situations where a one-to-one migration is technically impossible, because SharePoint Online has different limits than your on-premises farm. Some examples from our project:

Term Store: The shared tenant changes the rules. On-premises, each major project had its own very large term sets: spatial structures, material catalogs, asset hierarchies. Across all projects this added up to millions of terms. But the SharePoint Online Term Store is limited to 1 million terms per tenant, and this tenant is shared across the group. The old architecture where every project brings its own taxonomy simply cannot be represented in the cloud. We cover the details in part 4 of this series.

Lookup lists and column limits. Many taxonomy fields were historically implemented through lookup lists, and SharePoint Online limits lookup columns per query. Large structures hit limits that did not exist in the same way on-premises.

List View Threshold, URL lengths, structural depth. The 5,000 item threshold, 400 character path limits, and folder hierarchies from a time before metadata navigation was a realistic option.

Storage cost. On-premises storage was a one-time hardware item. In SharePoint Online, you pay per gigabyte permanently. If you migrate 25 TB containing countless document versions that differ only in metadata, you pay for redundant bytes for years. Version consolidation at this scale is not a nice-to-have, it is a business case. That is part 5 of the series.

The decision matrix

Criterion	One-to-one possible	Restructuring required
Information architecture	current, accepted	historically grown, inconsistent
Metadata/content types	consistent, maintained	project-specific sprawl
Taxonomy	within Term Store limits	own term sets per project, shared tenant
Permissions	group-based, documented	item-level, orphaned, unclear
Version estate	lean	inflated by metadata-only versions
Data volume	standard-tool friendly	several TB with transformation needs

As soon as two or more rows land on the right, “copy -> paste -> go live” is no longer a migration strategy. It is problem relocation.

What instead? Migration as transformation

In our 25 TB project, that means:

• New site and library structure based on a unified pattern instead of grown one-off solutions
• New, consolidated content types and metadata fields, centrally provisioned instead of assembled per project
• Taxonomy transformation: project-specific term sets become text, choice and lookup fields with clean mapping
• Consolidation of document classes with defined fallback rules for historical special cases
• Version deduplication: byte-identical version chains are detected and not migrated redundantly
• Verifiable completeness: every source file is checked against the target, with acceptance based on evidence instead of gut feeling

Why standard migration tools such as ShareGate, SPMT and others are no longer enough for these requirements, and why we built directly on the SharePoint Migration API, is covered in the next parts of this series.

Conclusion

The question is not “How do we get everything into SharePoint Online?” The question is: “Which of this should become our workplace for the next ten years?” A migration that only copies answers the wrong question.

---

You are facing a large SharePoint migration that classic tools cannot handle because of data volume, restructuring needs or SharePoint Online limits? We built exactly that and can support you from migration strategy to a dedicated migration pipeline. Get in touch.

All parts of the series:

1. Why not a one-to-one migration (this article)
2. 25 TB SharePoint migration: Why standard tools are not enough
3. The SharePoint Migration API in practice
4. Term Store at the limit: Taxonomy migration in a shared tenant
5. Migrate SharePoint version history intelligently
6. Provisioning at enterprise scale: PnP, throttling, permissions