A Windows profile folder is not the whole user. The person may depend on cloud-only files, email archives, browser state, certificates, passkeys, application databases, licences, printers and identity relationships that a simple copy does not reproduce.

Plan the migration around the work the user must continue, then choose the transfer tools.

Identify source, destination and identity

Record device ownership, Windows editions/builds, intended destination join/management state and every user profile on the source. Map each source identity to its destination identity: local, domain, personal Microsoft or Microsoft Entra.

Visible account names are not durable identity. Recreating the same name can produce a different SID and break file or application access. Decide whether an account is migrated, mapped, deliberately excluded or retained only in archive evidence.

Microsoft USMT includes users by default unless command-line user options constrain them. Define inclusion/exclusion explicitly so old technicians, departed users and service profiles do not move accidentally.

Inventory the real user state

Interview the user and inspect:

  • known folders and other working directories;
  • OneDrive/other sync roots and online-only files;
  • browser bookmarks, profiles and supported sync/export;
  • email accounts, local archives and signatures;
  • application data, templates, plugins and settings;
  • certificates, EFS/BitLocker recovery and security keys;
  • printers, VPN, mapped resources and specialist devices;
  • scheduled tasks, scripts and developer keys; and
  • accessibility and language preferences.

Mark the authority for each item: local source, cloud service, file server, application database or managed configuration. Do not copy a stale local cache over a newer service copy.

Choose the right migration method

Use service-native synchronisation or export for data whose service owns structure and permissions. Use ordinary file copy with counts/hashes for plain user files. Use vendor-supported backup/export for application databases and licences.

USMT is designed for managed PC refresh/replacement and can capture user accounts, files, OS settings and selected application settings through ScanState, LoadState and migration XML. It is configurable, not magical. Review its component manifests, user selection and exclusions for the installed application estate.

Avoid copying an entire profile, including hidden registry hives and caches, into a clean destination. That can bring corruption, stale tokens, junction loops and incompatible settings.

Prepare recovery and rollback

Confirm BitLocker and EFS recovery before capture. Back up unique data independently and test a sample restore. For a damaged disk, perform evidence-preserving recovery rather than a long live-state migration.

Secure migration stores: they can contain documents, profile settings and identity data. Encrypt them, restrict access, set expiry and avoid logging credentials. Capture tool version, command/configuration, selected users, warnings and store integrity.

Prepare installers and licence transfer/deactivation with the application owner. Do not wipe the source to free a licence until the destination completes its business test.

Stage the destination correctly

Build the destination on supported Windows and establish intended ownership, join, management, updates, encryption, security controls and backup before importing data. Create/sign into the destination identity according to the migration method.

Install supported applications from trusted sources. Restore managed settings through policy where possible instead of importing old local state that policy will overwrite.

Perform an initial transfer, review errors and exclusions, then reconcile changes at a scheduled final cutover. Freeze or clearly control source editing during the last delta.

Read the logs and reconcile exceptions

USMT or copy-tool success counts can conceal skipped locked files, path-length errors, access denials or excluded users. Classify every warning and error. Check file counts, total sizes and selected hashes by data set, not only one grand total.

For cloud sync, verify required files online and on the destination; placeholders are not local recovered data. For mail, open archives or allow full resynchronisation and test historic search. For certificates/keys, use supported import and prove the operation they enable.

Let the user test real work

Acceptance includes:

  • sign-in and account recovery;
  • opening, editing, saving and finding representative files;
  • email, calendar and archive access;
  • browser bookmarks and required authentication;
  • line-of-business transactions/reports;
  • printing, scanning, VPN and shares;
  • certificate or specialist peripheral use;
  • restart and offline/online behaviour; and
  • destination backup plus sample restore.

Test that excluded or departed identities do not have access. A migration that preserves data but broadens permissions is not successful.

Retire the source after observation

Keep the source powered off or isolated for a defined observation period rather than as an active fallback. Resolve discovered omissions through the same controlled process and update the migration record.

After owner acceptance and retention approval, remove the old device from identity/management systems, recover licences, revoke device credentials where appropriate and sanitise storage according to policy.

Migration is complete when the user can perform their actual work on the supported destination, every exception is explained, recovery is tested and the old PC is no longer an uncontrolled data source.