Most SharePoint migration checklists treat readiness as a technical problem. Inventory your sites. Check your workflows. Run the migration assessment tool. Done.
That framing misses the real reason migrations stall.
We recently helped a global pharmaceutical company complete a SharePoint migration that had been running — and stalling — since 2017. The environment wasn’t the problem. The data wasn’t the problem. The problem was that nobody had ever built a model that made the timeline real. Once we did, the whole project unlocked.
Case study: Five hundred sites migrated in four months.
This checklist is built from that experience, and from years of SharePoint migrations at Cloudwell. It covers the technical steps, but it starts with the questions most IT leaders skip.
Step 1: Understand the two timelines you're actually managing
The date everyone knows is July 14, 2026, when Microsoft ends extended support for both SharePoint Server 2016 and SharePoint Server 2019. After that: no security patches, no bug fixes, no safety net.
But there’s a second, earlier timeline (from next week) that’s tripping organizations up.
Microsoft retires individual features on their own schedules, independently of the server support date. And when your current environment depends on those features, the impact shows up during migration planning — not on the official end-of-support date.
The two most important pre-July deadlines happen next week:
- April 2, 2026: SharePoint 2013 workflows are fully retired across all Microsoft 365 tenants. If your organization uses these workflows, they cannot be migrated as-is — they must be rebuilt in Power Automate before your migration is complete.
- April 2, 2026: SharePoint Add-Ins retire in SharePoint Online. Any custom functionality or third-party solutions built on the Add-In model need to be replaced.
InfoPath Forms Services is also scheduled for retirement after July 14, 2026, meaning InfoPath-based forms need to be rebuilt in Power Apps before or during migration.
Full breakdown of the deadlines before July 2026
The organizations that get into trouble are the ones managing only one of these timelines. You need to build both into your planning from the start.
Step 2: Audit your environment
Not a surface-level inventory. A real assessment of what you have, what’s actually used, and what depends on what.
Site inventory
- Run a full report of all SharePoint sites, sub-sites, and site collections
- Identify site owners for each — you’ll need them for decisions and communications
- Flag sites with no activity in 12+ months as archive candidates
- Flag sites with no identifiable owner as a separate priority — these are the ones that slow migrations down
Content assessment
- How much data needs to move? Get a storage figure, not just a site count
- Where does sensitive, regulated, or IP-critical content live?
- Are there duplicate libraries or content that’s genuinely redundant?
- What content can be archived rather than migrated — reducing scope before a single file moves
Dependency mapping — the step most teams underestimate
- SharePoint 2013 workflows: run the SharePoint Migration Assessment Tool (SMAT) to identify which sites have active legacy workflows. These are your April 2026 blockers.
- SharePoint Add-Ins: identify any custom or third-party Add-Ins your teams depend on
- InfoPath forms: catalogue every form in use and map it to the process it supports
- Classic SharePoint alerts: flag any business-critical processes that rely on ‘Alert Me’ functionality
- Custom web parts and SPFx solutions: note which will carry forward and which need rebuilding
- Third-party integrations: identify anything connecting to SharePoint via legacy APIs
Cloudwell’s ‘Explore’ phase covers all of this in depth. See how the migration process works
Step 3: Build a model, not a guess
This is the step that separates migrations that complete on time from ones that drag for years.
When we took over the pharma project, the client needed a timeline. The honest answer was: we don’t know yet. But they had budget decisions to make and couldn’t wait six months for a full discovery. So we built a scheduling model instead.
The model took the number of sites, an estimated average time per migration based on our methodology, and the number of staff committed to the project — and generated a timeline. When the initial output showed late 2026, the client could see exactly why. Change the resource variable, tighten the migration approach, and the timeline shifts. It’s not magic. It’s just making the maths visible.
To build yours:
- Get a site count with complexity scoring (simple, medium, complex, legacy)
- Agree a standardized migration approach for the majority of sites — the more you can standardize, the faster the model runs
- Identify exceptions upfront: sites with heavy customization, legacy workflows, or compliance requirements that need individual treatment
- Calculate FTE commitment honestly — not aspirationally
- Build in buffer for the dependencies identified in Step 2
- Show the model to stakeholders. Let them see what hitting their deadline actually requires in terms of resource
If the timeline is unachievable with current resource, it’s better to know that in week one than in month six.
Step 4: Clean before you move
Every piece of content you migrate costs time and money. Every piece of redundant content you migrate costs time, money, and confusion on the other side.
Before migration starts:
- Archive inactive sites — remove permissions rather than deleting content, so nothing is permanently lost if a site owner comes back
- Remove stale documents, outdated pages, and obsolete libraries — involve site owners in these decisions
- Consolidate duplicate libraries where content has been spread across multiple locations
- Simplify permissions where possible — complex on-premises permission structures rarely translate cleanly to SharePoint Online’s model
The archive-don’t-delete principle is worth following as a default. In a large estate, you will encounter sites with no clear owner. Removing permissions and archiving is a reversible decision. Deletion isn’t.
Step 5: Decide where you're going — and configure it before anyone moves
For most organizations, the destination is SharePoint Online. For those with regulatory, data sovereignty, or compliance constraints that make a full cloud move impractical, SharePoint Server Subscription Edition (SE) is the supported on-premises path. Some use a hybrid of both.
Read our blog for a full breakdown of your migration options
Before any content moves, configure your destination environment:
Information architecture
- Design your hub site structure — how will sites be organised and connected?
- Define navigation: global navigation that applies across the estate, and local navigation owned by each team
- Decide your SharePoint vs Teams split: SharePoint Online for content shared with the broader organisation; Teams for internal team collaboration. Be explicit about this — most users have never had it explained
Governance and security
- Set up external sharing policies — consider domain-restricted sharing as a default rather than open external sharing
- Configure time-limited sharing links for content shared with partners or vendors
- Define sensitivity labels and retention policies before content arrives
- Establish site creation governance — who can create sites, how are they named, who owns them
Branding and templates
- Agree a corporate-approved site template that applies consistently across the estate
- Build and approve page layouts before migration — teams should be able to see what their new site will look like
- Set time zones and language settings correctly, particularly for global organizations
Step 6: Migrate in batches — communicate at scale
Trying to migrate everything at once is how migrations fail. Batching gives you control, visibility, and the ability to course-correct before problems compound.
Batch structure
- Start with low-complexity, low-sensitivity sites — build the process before you stress-test it
- Run a pilot migration with a small subset first: validate that content, permissions, and metadata transfer correctly
- Work through batches in order, validating each before moving to the next
- Keep a live log of site status: not started / in assessment / migrated / archived / exception
Communication
For large estates, manual communication with every site owner doesn’t scale. Automate it.
- Use Power Automate to generate batch-specific notifications: this is your site, this is your timeline, this is what we need from you
- Give site owners a clear deadline to respond — if there’s no response by a defined date, the site is archived
- Involve your internal comms team early — they will have a view on how migration is communicated across the organization, and their buy-in makes adoption easier
- Record training sessions and make them available on-demand — not everyone can attend live
Step 7: Validate, then hand over properly
A migration isn’t complete when the content arrives. It’s complete when site owners can manage their environment confidently.
Technical validation
- Verify all content has migrated successfully — spot-check document versions, metadata, and folder structures
- Confirm permissions are correct: check that users have the access they should have, and not the access they shouldn’t
- Test that workflows and automations built for the new environment are running correctly
- Redirect traffic from old on-premises URLs to new SharePoint Online sites
User handover
- Show site owners how to manage their own sites — editing pages, managing access, updating navigation
- Flat architecture and consistent templates make this much easier: when every site works the same way, one training session covers all of them
- Set up a support channel for post-migration questions — and a clear escalation path for issues that need IT involvement
Governance from day one
- Enforce lifecycle policies: who reviews sites annually, what happens to inactive content
- Define who can create new sites and under what conditions — the fastest way to recreate the governance problems of an on-premises environment is to let SharePoint Online sprawl unchecked
One more thing: what migration makes possible
A completed migration isn’t just a compliance tick. It’s the foundation for the tools that don’t work on an unsupported on-premises platform.
Copilot for Microsoft 365 requires a properly governed SharePoint Online environment to be useful — it surfaces content from across Teams, SharePoint, email, and calendar, but only if that content is accessible and organised. Power Platform automation runs natively against SharePoint Online data. And the security controls available in Microsoft 365 — domain-restricted sharing, sensitivity labels, time-limited access — are simply not available in the on-premises world.
The organizations that come out of this transition best aren’t just the ones that made it to the cloud by the deadline. They’re the ones that treated the migration as a chance to modernize, not just a box to tick.
Ready to start — or already stuck?
Whether you’re at the beginning of the planning process or partway through a migration that’s stalled, Cloudwell can help.
We’ve guided organizations through SharePoint migrations of every size and complexity — including a 500-site global project completed in four months.