Migrating a legacy SharePoint 2013 estate to SharePoint Online

Context

I joined a project to migrate a bank’s SharePoint 2013 farm to SharePoint Online. The farm had been growing for the better part of a decade: thousands of sites, a long tail of custom solutions nobody had documented, and an audit obligation that meant nothing could quietly go missing in transit.

Challenge

Three constraints pulled against each other. The migration had to be complete, with no orphaned content and no broken permissions. It had to satisfy compliance, which meant every step needed an audit trail. And it had to be invisible to the business, because thousands of people used these sites to do their jobs every day.

The hardest part was not the content. It was the customisations: farm solutions, InfoPath forms, and SharePoint Designer workflows that had no equivalent in SharePoint Online and had to be rebuilt rather than moved.

Approach

I started with an inventory rather than a migration: cataloguing every site collection, customisation, and permission structure so we knew what we were actually moving. That catalogue drove the wave plan, with sites grouped by business unit and dependency so each wave was self-contained and reversible.

We rebuilt the legacy customisations as modern equivalents. SharePoint Designer workflows became Power Automate flows, InfoPath forms became Power Apps, and farm solutions became SPFx web parts written in TypeScript. Rebuilding instead of lifting and shifting meant each wave landed on a supported platform instead of carrying technical debt forward.

Every wave ran through a GitHub Actions pipeline: provision, migrate, validate, report. Validation compared item counts and permission assignments before and after, so “zero data loss” was something we measured, not something we hoped for.

Outcome

The full estate moved to SharePoint Online with zero data loss and full compliance adherence. Business disruption stayed minimal, because waves were small and scheduled around each unit’s own calendar. Rebuilding the customisations instead of just moving them mattered as much as the migration itself: it left the client on a platform Microsoft still supports, rather than carrying the old technical debt into a new environment.