Verifying PC migrations & file transfers: CutoverCheck baseline guide

By J.E. Herizon LLC · Published September 27, 2026

Every Windows cutover comes down to one uncomfortable moment: the customer opens a folder on the new PC, and everyone watches to see whether the files are really there. CutoverCheck is a verification-only Windows app for repair shops, MSPs, and IT technicians. Before the move it captures a read-only SHA-256 baseline of the exact folders agreed for the job; after the move it compares the bytes; and it hands off a local, self-contained HTML report of what was checked — with matched, missing, different, unreadable, and not-checked results kept distinct. It never copies, repairs, moves, or deletes a single customer file.

Your old PC is full of "files" that were never really there

The 2026 migration trap isn't only silent copy failures — though those still happen. It's files that look present and are not. OneDrive and iCloud Files-On-Demand create placeholder entries: a file name, an icon, sometimes a size — but the bytes live in the cloud. File Explorer shows them like normal files, and a copy loop treats them like data. Sometimes the transfer never retrieves the bytes. Sometimes the old PC is wiped before anyone notices that a placeholder was never hydrated. By then, the "file" is gone.

CutoverCheck verifies what it can measure and is honest about what it can't. The capture pass identifies cloud placeholders from their provider reparse tags and reports each one as "not checked — cloud placeholder." It never opens them, so scanning never triggers a download or hydration. A stub is reported as not checked — never opened, never fetched, never counted as a match. That means the gaps surface while the old PC is still bootable, not after it's been wiped. The report tells you exactly how many placeholders sat inside the agreed scope; you decide what to do about each one. This detection is built into the current Windows build — it is real behavior, verified in the source, even though the landing page doesn't advertise it. The honest boundary is the point: the tool does not hydrate files, does not download them, and never pretends a stub is a verified file.

Five stages, each one gated

Every job runs the same real sequence — 01 Job → 02 Capture → 03 Map → 04 Verify → 05 Handoff — with lifecycle states and next-safe-action gating. You cannot verify a job before mapping is complete, and you cannot produce a final report while results are still pending. It turns an ad-hoc chore into a repeatable procedure a shop can standardize and train on.

The job records the customer-agreed scope: multiple selected source roots with stable IDs and display labels, an optional customer or reference label, and the capture time. The report shows exactly what was agreed — the denominator and the omissions are visible, which is the core of the dispute-proof story. Two kinds of exclusions are available: exact-file exclusions and directory-prefix exclusions, recorded through constrained UI, persisted, and printed in the report. A tech can exclude Temp\ or one junk file up front, so the handoff never argues about files nobody agreed to check.

All job state lives in a local SQLite database with explicit schema versions, migrations, and append-only, hash-chained event receipts — evidence survives restarts and upgrades, and nothing depends on a server. Archive a finished job (once all capture and verify operations are terminal) to free the Free-tier slot; archived jobs stay readable and exportable and can be reopened to measure again. And when a capture is interrupted, cancellation closes handles at safe boundaries and persists completed work; restart detects the interruption and offers a safe resume or abandon — without ever touching customer files.

Capture: a read-only SHA-256 baseline

This is the headline mechanic. Every selected, stable, regular file on the source PC is hashed with streamed SHA-256 and bounded memory, and the scan never writes to or modifies customer files. The edges are where the tool earns its keep:

• Change-during-scan: a file that is replaced or modified while being hashed receives ChangedDuringScan — never a digest-backed success. Nothing hides inside a green checkmark.
• Unreadable files: files that cannot be read (permissions, locks, I/O errors) are counted as Unreadable, distinct from missing or different.
• Reparse points and unsupported objects: each gets its own distinct "not checked" result, and reparse directories are never descended — coverage boundaries become visible instead of silently skipped.
• Honest capture interval: the baseline records capture start and end timestamps and per-item observation times; it explicitly does not claim to be an atomic point-in-time snapshot.
• Controllable: live progress (current root, file, counts, bytes, exceptions, elapsed) with cancellation at safe boundaries.

Carry the baseline on a USB stick

Export the baseline as a portable, versioned .cutovercheck bundle (suggested name baseline.cutovercheck) through the file picker. That is the air-gap story: the two PCs never need to share a network. Capture on the old machine, walk the USB stick to the new one, verify there — zero bytes over the wire, which also makes the bundle the right tool for machines that shouldn't be on a network at all.

Import treats the file as untrusted. Member names, types, counts, sizes, schemas, IDs, paths, totals, JSON, and SHA-256 integrity are validated before any usable state is created — you can open a bundle produced on a customer's machine or a colleague's stick without trusting that machine.

And the honesty detail that matters in this category: both the bundle and the report carry SHA-256 digests so their bytes can be re-checked, and the UI states it plainly — "integrity-checked but not signed." That is deliberate. The tool proves the record was not accidentally corrupted, and it says out loud that this is not a cryptographic signature and not a tamper-proof seal. If you adopt CutoverCheck in your shop, don't let your own marketing call it "signed" or "sealed" either — the app explicitly refuses that claim, and the refusal is the point.

Map each folder before verifying

Every source root requires exactly one destination selection before verification, and mappings are approved, timestamped, and printed in the report. This is what prevents the classic "files nested in the wrong folder" failure: the comparison target is made explicit rather than assumed.

Mapping validation rejects overlapping or duplicate mappings, root and state-directory conflicts, changed root identities, and any normalized relative path that would escape its destination root. Before approval, a preview shows how representative paths will resolve on the destination — the "crystal clear comparison target" is literally shown, not assumed.

Verify: distinct result states, nothing collapses

Verification is byte-level. A Matched result requires stable, readable destination bytes whose SHA-256 equals the baseline hash. Name, size, or timestamp alone can never produce a match. Every baseline file ends in exactly one closed state:

Matched · Missing · Different (size or hash) · Unreadable · ChangedDuringScan · NotCheckedCloudPlaceholder · NotCheckedReparsePoint · NotCheckedUnsupportedObject — or it stays pending. No summarizing into a lazy green check.

Two guards keep the numbers honest:

• Reconciliation: the baseline denominator is reconciled against category totals after every committed batch. Pending files are reported separately and never counted as matched. If totals do not reconcile, the report says "Treat this report as incomplete." The tool cannot emit a falsely-complete report.
• Honest denominator: files that exist only on the destination are explicitly outside the comparison and are described as "not inventoried" — a sparse job can't be dressed up as "everything matched."

Searching or filtering the result list never changes the global counts or the underlying frozen results — you can drill into exactly what was missing and still hand over numbers that reconcile. And a captured, mapped job can be verified and then re-verified after more data is copied over: one baseline, multiple comparison passes.

The manual checklist — where hash math ends

Hashing proves bytes, not behavior. So the workflow ends with a manual checklist. Per application, the technician records one of four attestation states — OpenedAndWorked · OpenedWithIssue · NotAvailable · NotChecked — with the expected task, a note, the technician's name, and a UTC timestamp. This is where real testing lands: Outlook sign-in, the QuickBooks file open, the printer test page.

Two boundaries keep the report honest:

• Attestations never mix into or affect the file-match percentages, and the report states that — a "I think it works" can't accidentally become "verified by hash."
• The tool never launches, opens, tests, or automates checklist applications. That is an explicit, documented boundary. Does CutoverCheck check applications? No — the checklist is the technician's attestation, period.

The handoff report: local HTML, not a PDF certificate

The handoff artifact is a single UTF-8 HTML file: no scripts, no remote resources, print-friendly CSS. It renders in any browser and opens on the customer's machine without CutoverCheck installed. It is deliberately not a PDF certificate, and it is not something anyone signs.

Two privacy modes: full detail includes relative paths, hashes, and reasons; summary-only hides paths and hashes and can anonymize root labels to "Root 1," "Root 2," and so on. Hand the customer a clean summary, keep the forensic detail internal — privacy is a feature, not a limitation.

The report embeds a SHA-256 digest over its own content, shown again in the footer, so the bytes can be re-checked after delivery. That proves integrity, not authorship — and the report's own wording stays honest about the difference.

Each report carries the complete evidence anatomy: method and scope, selected roots and exclusions, the mapping summary with approved timestamps, capture coverage, the destination comparison with byte counts, reconciliation state, coverage exceptions, the manual checklist, app and schema versions, the digest — and a limitations section titled "What the hashes establish — and what they do not." Quoted from the report: a matching hash means the selected bytes agreed at the times measured. It does not establish that applications work, that a file outside the agreed scope is intact, or that the old PC is safe to erase. Those are the technician's calls — backed by the checklist, not by an icon that looks fine.

Privacy: 100% local, read-only authority

Customer paths, filenames, hashes, and content are never sent anywhere. The core package requests no internet capability — the app runs with the network disabled, which you can verify by unplugging the NIC. The command surface has no copy, move, overwrite, delete, shell, or upload authority: verification only, no file changes — enforced by design, not just promised on a web page. Everything the app imports is treated as untrusted and defensively rendered, and diagnostic export is explicit and redacted of raw customer paths, filenames, content, and hashes.

Pricing: Free is the full workflow

Free is permanent — no account, no card, no trial clock — not a trial that expires into Pro. Pro buys capacity (concurrent jobs), not features: no measured capability is paywalled, and the whole shop runs on one flat price with zero per-seat math — a different pricing shape from the per-migration and per-user tools elsewhere in the category. If a Pro subscription ends, existing active jobs remain usable; nothing is deleted, no evidence is held hostage.

A before-you-wipe routine for your shop

1. Agree the scope with the customer: which folders, which exclusions, which applications you will open and test. Record it in the job.
2. Capture the baseline on the old PC. Note the cloud-placeholder count — those are the files that were never really there.
3. Export the .cutovercheck bundle to a USB stick — and a second copy for the job archive.
4. Move the data with your usual imaging or copy tool.
5. Import the bundle on the new PC, map each source folder to a destination, and verify.
6. Run the manual checklist for the applications in scope: state, note, technician name, UTC timestamp.
7. Export the handoff report — summary for the customer, full detail for the shop file.
8. Keep the baseline bundle archived. It stays readable and exportable with no subscription and no time limit.

The erase decision then belongs to you and the customer, informed by a byte-level record plus your own tested checklist — not by a folder view that can't tell a placeholder from a file.

← All articles

Use the current how-to guide