Your organisation has been running SharePoint Server for years. It works — or at least, it mostly works. People know where things are. Processes have grown up around it. Some integrations took months to build and nobody is quite sure what would happen if you touched them.

And now Microsoft has given you a hard deadline.

SharePoint Server 2016 and SharePoint Server 2019 both reach end of extended support on 14 October 2026. After that date, Microsoft stops issuing security patches, stops fixing bugs, and stops providing any form of compliance updates. For most regulated organisations — financial services, energy, healthcare, government — running unsupported infrastructure after that date is not a theoretical risk. It is a board-level liability.

You probably already know this. The question you’re sitting with isn’t whether to migrate — it’s how to do it without breaking the things that matter, without burning out your team, and without ending up with a Microsoft 365 environment that causes as many problems as the one you’re leaving behind.

That’s exactly the problem we solve.

After twenty years of SharePoint migrations — and eight of those spent as a SharePoint Architect inside Microsoft Services — we’ve looked inside more on-premises environments than we can count. The patterns are consistent.

None of this is a criticism. It’s the natural result of running a platform for a decade without the resource to actively govern it. We’ve seen it everywhere. We know how to work through it.

Most Microsoft 365 migrations that go wrong don’t fail because of technical problems. They fail because of planning problems: scopes that weren’t properly defined, stakeholders who weren’t engaged early enough, content that was moved without being understood, and environments that were rebuilt in the cloud without fixing the underlying architecture that was causing problems on-premises.

We’ve seen all of it. And we’ve built our migration methodology around preventing it.

Twenty years of SharePoint experience is a claim many consultancies make. Here is what ours actually means:

• Eight years working as a SharePoint Specialist within Microsoft Services — designing and delivering enterprise migrations for some of Europe’s largest organisations, with direct access to Microsoft engineering teams and product roadmap input.
• Migrations completed across financial services, energy, media, manufacturing, and government — sectors where compliance, data governance, and zero-downtime requirements are non-negotiable.
• Deep familiarity with every version of SharePoint Server from 2007 through 2019 — including the specific challenges of migrating legacy customisations, InfoPath forms, SharePoint Designer workflows, and farm solutions that have no direct equivalent in Microsoft 365.
• A track record of rescuing stalled migrations — brought in by organisations where a previous attempt had failed or stalled, to diagnose what went wrong and deliver the outcome the first attempt couldn’t.

We are not a generalist Microsoft partner with a SharePoint practice. SharePoint and Microsoft 365 is everything we do. It is the only thing we do.

Every migration engagement is scoped to your environment — but these are the components that every engagement includes, because every migration needs them.

Phase 1 — Discovery and Assessment (Weeks 1–3)

• Full environment inventory — A complete catalogue of your on-premises SharePoint environment: every site collection, subsite, library, list, and workspace. Documented, classified by type, and mapped to business ownership.
• Content analysis and risk classification — Every content area classified by volume, complexity, sensitivity, and migration risk. Identifies what can be migrated automatically, what needs manual handling, and what should be archived or decommissioned rather than moved.
• Custom solutions audit — Every custom web part, SharePoint Designer workflow, InfoPath form, farm solution, and third-party integration documented and assessed. Each one gets a clear recommendation: migrate, rebuild, replace with native M365 functionality, or retire.
• Permissions audit — Full analysis of your permission structure — broken inheritance, overly broad sharing, orphaned groups, and external access. Identifies every permission issue that needs to be resolved before or during migration.
• Stakeholder mapping — Identification of site owners, content owners, and key user groups across the business. Essential for change management and for ensuring the right people are engaged at the right stages.
• Discovery report and migration readiness score — A structured report presenting findings, risks, and recommendations. Delivered to your leadership team with a clear picture of scope, complexity, and what to expect from the migration.

Phase 2 — Architecture Design and Migration Planning (Weeks 3–5)

• Microsoft 365 information architecture design — Your new environment designed from scratch: hub site structure, site taxonomy, content type strategy, metadata framework, and navigation design. Built around how your organisation actually works — not how your on-premises environment happened to grow.
• Microsoft Teams and OneDrive governance model — Governance framework for Teams creation, naming, lifecycle management, and ownership — so the Microsoft 365 environment doesn’t accumulate the same ungoverned sprawl as the one you’re leaving.
• Migration sequencing plan — A phased migration schedule that sequences content by priority, complexity, and business impact. Critical content moves first; complex or sensitive content is handled with appropriate care; and business continuity is maintained throughout.
• Technical migration runbook — Detailed technical documentation of exactly how the migration will be executed: tooling configuration, cutover approach, rollback procedures, and validation checkpoints.
• Change management and communications plan — A structured plan for preparing your users: communications timeline, training approach, champions network design, and adoption measurement framework.

Phase 3 — Migration Execution

• Automated content migration — Migration of standard content using enterprise-grade migration tooling — with full fidelity checks, version history preservation, and permission mapping validated at each stage.
• Custom solution remediation — Rebuild or replacement of custom solutions that don’t have a direct migration path — including conversion of SharePoint Designer workflows to Power Automate, and retirement or replacement of legacy farm solutions.
• Phased cutover with validation gates — Content migrated in controlled waves, with a validation checkpoint at the end of each phase before the next begins. No phase advances until the previous one has been signed off.
• User acceptance testing support — Structured UAT process with key user groups — ensuring the new environment works as expected for the people who will use it daily, before full go-live.
• Go-live and cutover coordination — Full coordination of the final cutover: communication to users, redirection of links and bookmarks, decommissioning of on-premises access, and real-time support during the transition period.

Phase 4 — Adoption and Post-Migration Stabilisation

• User training programme — Role-based training for end users, site owners, and IT administrators — covering the new environment, key workflows, and how to get the most from Microsoft 365 features they now have access to.
• Champions network activation — Identification and enablement of internal Microsoft 365 champions across the business — the people who answer colleagues’ questions and drive organic adoption.
• 30-day hypercare support — Dedicated post-migration support for the first 30 days after go-live: rapid response to issues, iterative fixes, and a weekly check-in with your team to address anything that comes up in real-world usage.
• Adoption metrics and 60-day review — A structured 60-day review of adoption data, support ticket patterns, and user feedback — with recommendations for any further optimisation before we formally close the engagement.

October 2026 feels like enough time. It probably isn’t — not if your environment has any real complexity.

Here is a realistic timeline for a mid-sized organisation with a moderately complex SharePoint Server environment:

1. Discovery and assessment: 3–4 weeks. Cannot be shortcut — the migration plan is only as good as the discovery that precedes it.
2. Architecture design and migration planning: 2–3 weeks. Depends on the complexity of your information architecture decisions and the number of stakeholders involved.
3. Migration execution — phased: 8–16 weeks depending on content volume, number of custom solutions, and how many departments are involved.
4. Adoption, UAT, and go-live: 3–4 weeks. Includes user training, acceptance testing, and the final cutover.
5. Post-migration stabilisation: 4–6 weeks of hypercare before the environment is running independently.

That’s a realistic total of five to seven months for a migration that is properly planned, properly executed, and properly adopted. For larger or more complex environments, it can be longer.

If you begin the discovery process in May 2026, you are threading a needle. If you begin in July, you are running out of road.

It is worth being clear about what end of support actually means in practice, because it is often misunderstood.

• Your SharePoint Server environment does not switch off on 15 October 2026 — It continues to run. Your files are still there. Users can still access it. In the short term, nothing obviously breaks.
• What stops is Microsoft’s obligation to fix it — From that date, any security vulnerability discovered in SharePoint Server 2016 or 2019 will not receive a patch. Any bug found will not be fixed. Any compliance gap introduced by a regulatory change will not be addressed.
• For regulated industries, this is immediately material — Financial services firms, energy companies, healthcare organisations, and government bodies operating under data protection, information security, or sector-specific compliance frameworks cannot knowingly run unsupported infrastructure that handles sensitive data. Legal and compliance teams will not sign off on it.
• Cyber insurance implications — A growing number of cyber insurance policies exclude claims arising from vulnerabilities in unsupported software. Running SharePoint Server past end of support could invalidate coverage at precisely the moment you are most exposed.
• The longer you run past it, the harder the migration becomes — Microsoft 365 continues to evolve. The gap between an unsupported SharePoint Server environment and the current Microsoft 365 platform grows every month after October 2026, making the eventual migration more complex and more expensive.

The cost of a rushed migration

The organisations that end up with the most problems are not the ones that planned carefully and hit a complication. They are the ones that left it too late and had to cut corners.

A rushed migration typically means: content moved without being understood, governance skipped because there was no time to design it, user training compressed or eliminated, custom solutions left broken because there was no time to remediate them, and a Microsoft 365 environment that is messy from day one and gets messier from there.

The cost of fixing a poorly executed migration — in IT time, user frustration, re-work, and lost productivity — is almost always significantly higher than the cost of doing it properly the first time.

The next step

The most useful thing you can do right now is understand exactly where you stand. Not a sales pitch — a clear picture of your environment’s migration complexity, your realistic timeline, and what a properly planned migration would involve for your specific situation.

That’s what our Migration Readiness Call is for. Thirty minutes with a senior SharePoint architect. We’ll ask about your environment, give you an honest assessment of your timeline options, and tell you what we’d recommend — whether you work with us or not.