The migration finished Sunday night. Monday morning everyone says “looks fine.” And it does, files open, search works, nobody’s locked out. The validation gets marked done.
The problem is that the failures worth worrying about aren’t the loud ones. They’re silent: retention not enforced, an external-sharing default that quietly loosened, permissions that resolved differently than the old farm. None of those announce themselves on day 1. They surface around day 30, which is exactly when everyone has moved on and stopped watching.
That gap is the whole reason this post exists. If you only validate the morning after cutover, you are checking on the day the least is wrong.
Why a schedule, not a checklist
Doing every check on day one feels thorough. It isn’t. Some failure modes need time to become visible, a site that was active before and silent after only reads as a problem once you have weeks of post-cutover activity to compare against. Run that check on day 1 and every site looks “silent.” Run it on day 30 and the real abandonment pattern stands out.
So validation is three distinct passes, each timed to when its failures actually surface.
Validation schedule
Three passes, three timeframes. Each one is timed to when its failures actually become visible.
Pass 1: 24-hour validation
The morning after cutover. Goal: confirm the obvious is working.
- Search index spot-check. Query 10–20 distinct keywords across roughly 10% of migrated sites. Expect gaps. SharePoint Online uses continuous crawl, and how long full indexing takes depends on volume, file size, and metadata. Individual items often surface within an hour, but fully indexing a large migration can take a day to several days, with no fixed window. Note what’s missing and revisit on day 3. If a specific library still isn’t showing up later, use the Reindex option on that library or site to queue a recrawl. You can’t force a full tenant crawl, but you can nudge a specific scope.
- Permission spot-check. Pick 10 sites at random and verify the actual user list matches the pre-cutover audit. Permission-mapping drift is cheapest to catch now.
- Source farm read-only. Confirm the old farm is still locked. People will try to edit there for the first 48 hours, and you don’t want two live copies.
That’s the pass. Short by design. Day 1 is for catching breakage, not drift.
Pass 2: 72-hour validation
Three days post-cutover. Goal: confirm the rules that protect your content are actually covering it.
- Retention. Retention policies are scoped to locations, sites, OneDrive accounts, or the whole org, not to individual files. Migrated content inside an included site is covered automatically, with one catch: the site has to finish indexing before retention is enforced. Two things to watch. First, a policy scoped to a specific site URL won’t catch the new SharePoint Online site, because it has a different URL, re-point it. Second, retention labels are not policies: they do not travel with files through a migration and must be re-applied via an auto-apply policy or a library default label. And if your migration tool rewrote files’ Modified dates, any label whose retention is “based on last modified” just recalculated its clock.
- DLP. Same shape as retention. DLP policies are tenant- and location-scoped, so migrated content is covered automatically, but a policy scoped to specific site URLs needs the new URLs added, and content has to be indexed before DLP can evaluate it. If you’re regulated, this is the audit-finding-prevention pass.
- External-sharing posture. New tenant defaults are usually stricter than the old farm’s. Pull the external sharing report and flag anything granted in the past 72 hours that was previously locked down.
- Search re-validation. Re-run the day-1 search queries. More should resolve now. For anything still missing, Reindex the specific library rather than waiting on the whole tenant.
Pass 3: 30-day validation
This is the one that gets skipped. It’s also the one that catches the failures that cost real money.
- Usage diff. Compare active site usage from before cutover (last 90 days on the source farm) against the first 30 days on SharePoint Online. A site that was active before and silent after is a failure mode. Usually a broken permission or a comms gap nobody noticed.
- Abandoned-site sweep. Sites nobody opened in the first 30 days are candidates for archive or delete. In my experience the abandoned bucket is always bigger than the client expects, but treat that as a field observation, not a statistic. The cleanup window is now, while the migration is still fresh in everyone’s mind.
- Orphaned permissions. External users who never logged in, service accounts still listed, AD groups that resolved differently than expected. SharePoint audit data is available from day 1. Activity logs are retained 180 days on standard plans, a year on E5, so this isn’t about waiting for logs to exist. It’s about the analysis window. A month of genuine post-cutover activity is what makes a “this account has touched nothing” pattern actually mean something.
- Source farm decommission readiness. If pass 3 is clean, you’re cleared to decommission the old farm.
The day-1 pass tells you the migration tool worked. The day-30 pass tells you the tenant around the content still does.
What you’re really validating
None of these passes test the migration tool. The tool is fine; it moved the bytes. What you’re validating is the operational state around those bytes: that retention still covers the right sites, that the right people still get notified (on a mechanism that won’t be retired in two months), that the permission model still locks down what it should.
The single highest-leverage move isn’t any individual check. It’s putting all three passes on the calendar before you start the migration. Day 1 you’ll do anyway. Day 3 and day 30 are the ones that quietly fall off the list because nothing is on fire, and “nothing on fire” is precisely the condition under which the expensive failures are taking root.