Windows migrationAlpha / In DevelopmentNo release date

Blackwire Migration — Move Applications, Settings & User Profiles to Another PC

Blackwire Migration is being built to analyze an old Windows PC, package the programs and user data you choose, and restore what it can on the destination PC. When something needs a clean reinstall or reactivation, the goal is to say so instead of pretending the migration worked.

Blackwire Migration development build showing Ready to Migrate, Needs Review, and No Action Needed program groups
Development preview: program choices are grouped by expected migration outcome before the package is created.

In Development

Still being designed, engineered, and tested.

Blackwire Migration is not released, there is no public download, and there is no planned release date. Features, screenshots, workflows, naming, and capabilities can change as testing continues.

ProgramsRestore applications using the best evidence available
User profilesMove selected Windows user data separately
Verified packagesCheck that required migration content is actually present
Honest resultsCall out reinstall or reactivation when needed

What it is

A Windows migration tool for moving programs, settings, and user profiles to another PC.

The long-term goal is simple: make a PC replacement less dependent on reinstalling every application by hand, hunting down old installers, moving user files one folder at a time, and trying to remember how the old machine was configured.

Blackwire Migration is being built around one migration platform, but program migration and profile migration stay separate so the user or technician can choose exactly what gets moved.

Two workflows

Programs and user profiles are related, but they are not the same migration job.

Keeping them separate makes it easier to control what moves and avoids treating a user profile copy as proof that installed software is ready on the new PC.

Program Migration

Blackwire analyzes installed applications and the installation evidence available on the source PC. Depending on the program, it may be able to reuse a cached installer, use an exact package identity, restore required files and selected configuration, handle dependencies, and then verify the result.

If a program cannot be safely reconstructed, Blackwire should say that a reinstall is required instead of copying files and calling the job finished.

Profile Migration

Profile migration is being designed for user files, Desktop, Documents, Pictures, selected application data, profile-specific configuration, and applicable per-user Windows state.

A migration can include one Windows user profile, or no profile at all when the job is programs-only. Technician-oriented workflows are expected to expand that capability later.

Development preview

The current Home workflow is already being exercised end to end.

These are screenshots from the active Alpha build. They are development previews, not final-release artwork, and the interface may change as the migration engine is refined.

Start with the old PC or an existing package.

The Home workflow can analyze the current PC to build a new migration package or open a package that was created earlier.

The goal is to keep package creation separate from destination-side restore so the migration file can be moved to the new computer and reviewed there.

Blackwire Migration Home development screen with Analyze This PC and Open Migration Package
Home workflow: analyze the old PC or open a migration package created earlier.
Blackwire Migration analysis progress screen showing programs, user profiles, and migration evidence checks
Analysis is read-only: programs, profiles, installer evidence, dependencies, and migration requirements are checked before anything is packaged.

Choose the programs and user data that actually belong in the package.

Programs are grouped by expected outcome so ready items can be separated from applications that need review or do not need migration action.

The profile screen then lets the user choose Windows user data separately and review the package contents before creation.

Blackwire Migration Windows user profile selection and package review development screen
User profiles stay separate from program choices, with a package review before the migration file is created.
Development previews shown. The interface, labels, workflows, and features may change before any public release.

Expected workflow

Analyze first. Build the plan before changing the destination PC.

The restore side is being designed to look at both the migration package and the new Windows installation before it decides what should happen to each selected application.

  1. Analyze the old PCInventory applications, profiles, installers, dependencies, and other migration evidence.
  2. Create the migration packageWrite the selected programs and/or profile data to a verified .bwmigrate package.
  3. Open it on the destinationInspect the new Windows installation and see what is already present.
  4. Build the migration planChoose the safest available restoration path for each selected application before changes begin.
  5. Migrate and verifyPerform the selected work and report anything that still needs reinstallation, reactivation, or technician attention.

The migration package

A package needs to contain what the restore will actually need.

One of the biggest areas under active development is package completeness. Finding out on the new PC that an installer is missing a CAB, patch, transform, or other required source file is exactly what this system is supposed to catch earlier.

Evidence currently being captured or evaluated

  • Installed application identity and version
  • Windows Installer / MSI information
  • ProductCode and UpgradeCode information
  • Cached installer media when available
  • MSI patches and transforms when recoverable
  • Installer source and provenance information
  • Application files and selected configuration
  • Shortcuts and launch information
  • Shared runtimes and dependencies
  • Selected per-user and per-machine state
  • Integrity hashes and package verification data

Why completeness matters

Copying an EXE is easy. Recreating an installed application in a way that behaves correctly on another Windows installation is the hard part.

Blackwire is being designed to look at the evidence available for each program and decide whether it has enough material for a reproducible restore. If it does not, that should be visible before the migration is committed.

A .bwmigrate package is still a development format. Its contents and structure may change while the migration engine is being hardened.

Current development work

This is where most of the engineering work is happening now.

The project is still Alpha. We are spending more time on migration accuracy, package completeness, recovery, and verification than on pretending every application can be moved automatically.

Application intelligence

Application discovery, exact identification, installer-source recovery, MSI/MSP/MST evidence, provenance, and reducing one-off application special cases.

Dependencies & planning

Visual C++, .NET, shared-runtime detection, dependency preflight, and deterministic migration planning before destination changes are made.

Package reliability

.bwmigrate completeness checks, integrity verification, recovery safeguards, diagnostic evidence, and detecting missing restore material before the destination phase.

Restore verification

Application launch and usability checks, licensing/reactivation detection, reinstall decisions, older application testing, and clearer migration outcomes.

Architecture work

Keep application knowledge separate from the core migration engine.

We are also redesigning the architecture so application identities, dependencies, compatibility information, installer behavior, and migration recipes can be updated as knowledge instead of requiring the entire program to be rebuilt every time another application is encountered.

Migration results

A migration result should describe what actually happened.

Blackwire is intentionally conservative about calling something successful. An application simply opening for a few seconds is not enough evidence that the job is complete.

Migrated / VerifiedThe application or selected data was restored and the checks performed so far support the result. A verified result may still carry clearly listed warnings.
Provisional / Needs ReactivationThe application may be reconstructed or otherwise usable, but it still needs review, a product key, vendor sign-in, or activation on the destination PC.
Reinstall Required / FailedSometimes the correct answer is a clean reinstall. That is not hidden as a successful migration. A real failure is reported separately when the requested operation could not be completed.
Reinstall Required is not automatically a Blackwire failure. For some applications, preserving the user's settings or data while directing the technician to reinstall the program is the safer and more reliable result.

Licensing and activation

Migration is not a license bypass.

Commercial software may still require the user's existing product key, a vendor account sign-in, or reactivation on the new computer. Hardware-bound, account-bound, non-transferable, or vendor-protected licenses are not something Blackwire Migration is intended to defeat.

The software is being designed to report Needs Reactivation when that is the real state instead of claiming the application is completely ready.

Home and technician workflows

One migration engine, different levels of control.

The current plan is one shared application-migration engine. Home and Business should not become two unrelated migration products.

Technician/business workflows are expected to add capabilities such as offline or attached source migration, multiple-profile work, domain-related migration, and other advanced controls. Those details are still being designed and are not final feature commitments.

Alpha / In Development

No public release and no planned release date.

Blackwire Migration is still in active design, engineering, and testing. The page will be updated as the migration engine, package format, restore verification, and technician workflows mature.