How it works
All 12 phases. One screen. Zero user interaction.
Every device that goes through Nexune Migrate runs the same 12-phase state machine. It's idempotent, resumable, and signed end to end. Below: every phase, what happens, and why it's built this way.
- 01
Pair tenants
An admin connects source + destination Microsoft 365 tenants over delegated AAD.
Why this matters
Delegated tokens (not consented client secrets) mean we never hold a long-lived admin credential.
How it works under the hood
Each side is authorized with a delegated sign-in flow that pins the expected tenant on return. Tenant credentials live in a per-customer key vault, isolated by side. Connections are health-checked against the destination tenant before any wave can be activated against the pair.
- 02
Discover devices
A managed-device scan enumerates every Windows endpoint in the source tenant.
Why this matters
You can't migrate what you haven't seen. Re-runs are safe — they refresh state without double-counting devices.
How it works under the hood
Devices are pulled from the source tenant's management endpoint and reconciled against what we've seen before. Each device gets a 0–100 readiness score with blockers surfaced explicitly: encryption state, last-sync staleness, compliance posture, and autopilot eligibility.
- 03
Map users
Source UPN → destination UPN, with a strategy and an audit trail.
Why this matters
Most M&A migrations have at least one identity-rename surprise — an employee whose login name has to change to fit the new domain. Pick a strategy or upload a CSV; we keep the receipts.
How it works under the hood
Mapping strategies cover the common cases: UPN prefix preserved, regex transformation, attribute-derived from the directory, or explicit CSV. Mappings into privileged destination roles take a separate approval path. Separation of duties is enforced — the operator who creates a mapping can't be the one who approves it.
- 04
Build a wave
Pick devices, schedule, and hand it off.
Why this matters
A "wave" is the unit of audited change. Big waves take a second approver. Hard caps keep blast radius bounded.
How it works under the hood
The wave wizard walks pair → device selection (with readiness filtering) → name and schedule. Above 100 devices, a second approver is required. Above 500, the wave is split. Every state-changing call carries an idempotency key, so retries are safe.
- 05
Approve
A hardware security module signs over the canonical wave manifest.
Why this matters
A cryptographic signature, not a checkbox. The bytes signed at approval are the bytes the device agents execute against — no in-between mutation possible.
How it works under the hood
Approvals are produced by an HSM-backed signing key and carry a freshness window. The signature is bound to the wave's canonical manifest; it cannot be re-used on another wave. Above the production threshold, two distinct approvers are required.
- 06
Dispatch
Signed commands flow to per-device queues, in order.
Why this matters
Per-device ordering, natural idempotency, and TTLs aligned to the approval window. Devices pull from a queue they can't poison.
How it works under the hood
Each device has its own session-keyed queue. The on-device agent verifies the command's signature against pinned control-plane keys before acting on anything. Stale commands fall off the queue automatically.
- 07
Prepare on device
BitLocker keys escrowed, profile snapshot taken, agent ready.
Why this matters
If anything goes wrong from here, we can roll back to a known-good state. The recoverable window closes only after the source side is cleaned — and only then.
How it works under the hood
The agent escrows the existing BitLocker recovery key, snapshots the user profile, and confirms the destination tenant is reachable. Migration doesn't move past this phase unless the rollback path is verified.
- 08
Migrate identity
Leave the source tenant, join the destination, re-enroll in management.
Why this matters
The surgery. Authorized by a short-lived, device-bound token that's good for this one device, this one operation.
How it works under the hood
The agent uses a short-lived authorization token, bound to the device's hardware identity, to perform the tenant leave-and-join sequence. The token expires in seconds and is replay-defended at the control plane.
- 09
Migrate profile
The user profile re-binds to the destination identity, on the same machine.
Why this matters
This is where profile-hijack attacks would happen if we let them. The agent will only accept a destination identity that matches what the control plane authorized — no others.
How it works under the hood
The destination identity is resolved by the control plane and stamped into the signed command. The agent compares and refuses to proceed if it doesn't match. The user profile is then rebound; Outlook, Teams, OneDrive, and other apps re-anchor to the new identity.
- 10
Migrate content
OneDrive, SharePoint, mail — picked up automatically with the new identity.
Why this matters
Content sync is pre-staged before identity swap. The user signs in once after migration; everything is where it was.
How it works under the hood
Files and mail are re-anchored to the new identity on first sign-in. For customers with very large mailboxes, content is pre-staged ahead of the wave so the post-migration experience is instant.
- 11
Verify
The device confirms; the control plane confirms; the user portal updates.
Why this matters
The wave isn't done until every device echoes "done." Stragglers surface immediately into Quarantine.
How it works under the hood
The agent reports verification status back to the control plane, which flips the device's state and notifies operators in real time. Anything that doesn't verify on time routes to a triage workflow rather than blocking the rest of the wave.
- 12
Notarize
Every action sealed in a tamper-evident chain. Signed. Blob-immutable for 7 years.
Why this matters
You don't prove a migration happened by digging through logs after the fact. You prove it with a signed receipt you can hand to your auditor.
How it works under the hood
The audit log is hash-chained as it grows. A background process seals each per-customer batch with an HSM signature and ships it to write-once storage with a 7-year immutability lock. The resulting receipt is a portable artifact your auditors can verify independently.
After the wave
The chain doesn't end at notarization.
Every receipt is a portable artifact. Hand it to your auditor; they can verify the hash chain and the HSM signature independently — no Nexune tooling required. The same primitives carry into reporting: signed PDF wave summaries and monthly usage statements, generated from the same ledger.
See the state machine running on a real device.
The fastest way to understand the 12 phases is to watch them happen.