When a machine is replaced or Windows is reinstalled, OPBS moves what
you actually care about — Documents, Desktop, browser profiles, chat
histories, game saves, per-user settings — from your old disk image
(or the old drive itself) onto the running new install.
Dry-run by default, refuses up front,
verifies after. And it hands you a winget
manifest so your apps come back too.
Three tiers, each with its own mechanism — and its own honest boundary.
| Tier | What | How | Status |
|---|---|---|---|
| 1 · Profile data | Documents, Desktop, Downloads, Pictures…, %APPDATA% /
%LOCALAPPDATA%, known app data stores |
File copy with per-file journal and MD5 verification | ✓ shipped |
| 2 · Per-user settings | Curated per-user registry keys — browsers, terminals, app
preferences living in NTUSER.DAT |
Key-level offline hive transplant: load, copy key by key, count-verify, unload | ✓ shipped |
| 3 · Your programs | Installed-app inventory from the source's uninstall keys | winget-import.json plus a human-readable
reinstall list |
✓ shipped |
winget import on the new machine, and OPBS builds that
manifest for you from what it finds on the old one.
Every source funnels into the same thing OPBS already reads better than anyone: an NTFS volume and its user profiles.
Point at an .opbs, Macrium .mrimg or
.mrimgx backup and pull the profiles straight out of
it — no original hardware needed. OPBS reads
the Macrium formats natively ↗,
chains included.
Pull the disk, plug it in — the classic two-machine swap. OPBS reads the volume directly, finds the profiles and inventories what's on them.
The flagship path: restore the old machine into a virtual disk on the new PC, attach it, and migrate the profiles onto the live OS. No bare-metal restore on the target, no second machine needed.
Mount a partition from any image as a real drive letter via WinFsp and migrate from there — reads are served on demand, the image is never written.
The same trust contract as OPBS restores, applied end to end.
Profiles and SIDs on the source, app scan through the knowledge base, known store detection (mail, browsers, chat, saves), and a free-space check on the target.
Every file move with sizes, every registry key, every refusal with
a reason — and a plan hash. migrate plan exits 1 when
refusals exist, so scripts can't sleepwalk past them.
--execute requires handing back the hash the plan
printed. Every file is journalled, so a crash mid-profile leaves
a journal you can --resume. Existing target files
abort that profile unless you pass --merge.
A full MD5 pass over what was copied, then
report.json + winget-import.json under
.opbs-migrate/ — migrated, skipped, refused and
needs-reinstall, with paths.
--include.
A GUI over the exact same CLI verbs — five steps, nothing off-script.
Pick a live system drive or an image (with partition and
passphrase), then choose the profile to migrate. Listing is a
cheap in-process scan of Users\ — no store walk.
Point at the existing profile folder on the new install. OPBS verifies it really is a directory before you can continue — no discovering a typo at execute time.
Totals, plan hash, registry keys, winget reinstall hints and every refusal in the open. The execute button stays disabled while any refusal exists.
Registry transplant (only offered when elevated), owner/SID rewrite (on by default when elevated), and merge / resume / no-verify switches for the special cases.
Progress streams from the copy journal as files land, and ends in the full report — summary, registry outcomes, owner status, and artifacts you can open with one click.
The wizard spawns the CLI in a child process; JSON arrives via files and passphrases via short-lived temp files — never on the command line, never on the main loop.
migrate plan against the newest image
on a cron you pick, records the result next to the image in
opbs-migrate-drill-history.json, and only raises an
alert after several consecutive failures.
Why rehearsals matter ↗
Every verb is scriptable — read-only JSON out, execute gated on a plan hash.
:: read-only inventory of an image partition OPBS.exe --cli migrate inventory "D:\Images\old-pc.mrimg" --partition 1 :: dry-run plan — prints the plan hash, exits 1 if anything is refused OPBS.exe --cli migrate plan "D:\Images\old-pc.mrimg" --partition 1 --profile all :: execute — hand the plan's hash back; add --registry in an elevated shell OPBS.exe --cli migrate run "D:\Images\old-pc.mrimg" --partition 1 --profile alice --target C:\Users\alice --execute --plan-hash <hash> --registry :: the same thing from the live machine you are sitting at OPBS.exe --cli migrate inventory --live
--json / --json-out FILE — machine-readable plan, run and inventory output for automation.--apps-db my.json — merge your own app entries over the 43-app seed (validated on load).--passphrase — encrypted source images; the GUI hands it over as a short-lived file instead of argv.--folder / --target / --profile — scope a single folder or profile instead of everything.Where per-app data lives, which registry keys are safe to move, and what to reinstall — as a plain JSON file in the repo, not a black box.
{
"id": "google-chrome",
"name": "Google Chrome",
"data": ["%LOCALAPPDATA%/Google/Chrome/User Data"],
"registry": ["HKCU/Software/Google/Chrome"],
"winget": "Google.Chrome",
"class": "data+settings"
}
data, data+settings, reinstall-only (AV, Office, COM-heavy — data paths ignored), ignore.%TOKENS%, no drive-absolute paths, Publisher.Package winget shape.--apps-db, and open a PR. Entries land with the next release.What OPBS won't do — because a migration tool that oversells itself is worse than one that doesn't.