Migration Verification | pH7x Systems

Who checks the checker

At the end of a migration somebody signs a piece of paper. The evidence behind that signature almost always comes from the tool that performed the move, because it is the only thing that was watching.

That is not an accusation. A migration tool is built to move things and to tell you how the moving went, and it does that well. But a report by the party that did the work is the party's account of its own work, and no amount of detail changes what it is. When something turns up missing eighteen months later, the question is not whether the report was thorough. It is whether anybody could have checked it.

A migration cannot be verified afterwards

This is the part that surprises people, and it decides everything else about this tool.

Decommissioning the source is the whole point of a migration. Once it is gone, there is nothing left to compare the destination against, so a verification that begins at sign-off is not a verification at all. It is an inventory of the new place, and an inventory cannot tell you what is absent from it.

The comparison needs two reads: one before the move, one after. The first is the only irreplaceable artefact in the process, and nobody can produce it retroactively. A project that did not take one can never be verified, and that is worth knowing at the beginning rather than at the end.

What gets compared, and what each answer is worth

Eight dimensions, and every one of them is published with what it cannot establish. That second column is the reason this exists. Each dimension is compared only where both reads carry it, and the record names the ones it could not compare.

Dimension	Establishes	Does not establish
Presence	a file with this path exists on both sides	that it is the same file: a renamed or moved file reads as one missing and one extra. Folders are walked, not compared, so an empty folder that did not arrive is not reported
Count	how many items the estate holds on each side, as one figure for the whole estate; folders are not counted	which items differ, or in which folder
Size	the byte size matches	that the content matches
Content	equality of the hash SharePoint and OneDrive report (quickXorHash), only if both reads carry it	anything at all, if only sizes were read
Authorship	whether the recorded creator of each file survived, or became the migration account	who last modified it; who the author was, once the source is gone
Versions	how many versions each file carries, when both reads asked for them	whether the ones dropped mattered
Permissions	who was granted what directly on each file, when both reads asked for it	whether a broader result was intended; who a sharing link was granted to
Sharing links	the scope and type of each link on each file, for example an anonymous view link	which link it is, whether it still resolves, or whether anyone was still using it

A migration report has no second column. It does not need one, because its purpose is to conclude that the migration succeeded.

Three rules the record will not break

An item nobody could read is not an item that went missing. If a folder could not be opened, a file disappeared while it was being read, or a file's permissions could not be read, the result is unknown, with the reason and the side it fell on. Reporting it as missing would sound more useful and would be a claim nobody established. Reporting it as fine is worse.

The one case this rule cannot catch is an item the reading account cannot see and was never refused: it is simply not in that read. That is why both reads must be taken by the same identity. The comparison refuses two reads that record different permissions, but a read does not record which account took it, so two people with the same permissions are not told apart.

Two files of equal size are not the same file. If content was compared by size alone, the record may say many things but it may never say the content matched. The strongest honest answer is unknown, and the software refuses to write anything stronger.

There is no percentage. No score, no grade, nothing to put on a slide. 96% migrated is what a reader substitutes for the table above the moment it is offered, and the substitution is what destroys the document. There is nothing here to aggregate, deliberately.

What it never does

It never moves anything. The moment it writes to either side it becomes the producer, and the whole point is gone.
It never remediates, recommends or ranks. It says what is.
It never requires us. The record is canonical, digested, and checkable by anyone you hand it to, on their own machine, with no account and no licence.
It never reports an item it was refused as missing.

Where it is

Available means implemented and tested at the published engine revision. Unverified means implemented, but never recorded working on a real library. Not implemented means no code exists.

Part	State	What that rests on
The contracts, `migration-read/1.0.0` and `migration-verification/1.0.0`	Available	Published with engine 1.0.0b9, whose tests validate the records it produces against them
The comparison, `migration-verify`	Available	It works on two read files and needs no tenant; the engine's tests exercise it on synthetic reads
Reading one SharePoint Online or OneDrive library, `migration-read`	Unverified	Implemented through Microsoft Graph and tested only against simulated Graph answers; reading version history has no test. The engine's proof registry holds no run against a real library
SharePoint Server, file shares, Teams, Exchange, whole sites or tenants	Not implemented	A read covers one library. The contract allows a source with no tenant, such as a file share, but nothing in the engine reads one

So what exists covers a move between two SharePoint Online or OneDrive libraries, and the reader has no recorded run against a real one. A move from SharePoint Server, including to Subscription Edition, is not covered: the engine has no reader for a farm.

It is part of the same open source engine as the governance rules, under the same licence, and it inherits the vocabulary: a difference is a fail, what could not be established is unknown, a match produces no finding at all, and coverage is stated in words. The record lists what it compared, so silence about a file means it matched on every dimension compared, never that nobody looked.