Migrating a Device Between Tenants — Azure AD Joined → Azure AD Joined
An end-user and helpdesk guide to the Cloudiway Agent device migration. It walks through every phase of the process and explains, line by line, what each log message means — including the warnings and errors that are normal and the ones that need attention.
1. What this migration does
Your PC is currently joined to one company's Microsoft 365 / Entra ID (Azure AD) tenant. This process detaches it from that source tenant and re-joins it to a different target tenant — without wiping the machine or losing your local profile, files, Outlook profile, OneDrive sync, or BitLocker protection.
The big idea
What runs the show
A small program, CloudiwayAgent.exe, performs the
migration in several stages, with one or more reboots in between. Because Windows can't re-key a profile
that is currently in use, the work is split across reboots and driven by scheduled tasks
that the agent creates. Everything the agent does is written to a log so administrators can follow along.
2. Before you start
- •Plug in & stay on power. The PC will reboot 2–3 times automatically. Do not shut it down.
- •Be online. The agent talks to the Cloudiway platform and to Microsoft to leave/join tenants and register the device.
- •Save your work and close apps (especially Outlook and OneDrive) before the migration is triggered.
- •Know your new credentials. After the migration reboots, you sign in with your target tenant account on the Windows login screen.
- •Have your BitLocker recovery key handy as a precaution, in case you are prompted during a reboot.
During reboots you may see on the lock screen
This is expected. Let it run.
3. The journey at a glance
Six phases, separated by automatic reboots. The first three run while the PC is still joined to the old tenant; the last three run after reboots, on scheduled tasks, to finish joining the new tenant.
| # | Phase | When | What happens |
|---|---|---|---|
| 1 | Pre-flight & prep | Before reboot | Verify the agent is complete, create a temporary admin, tell the platform to clean up the source device record. |
| 2 | Leave source tenant | Before reboot | dsregcmd /leave + cleanup; remove old Intune/Autopilot traces. |
| 3 | Provision & reboot | Before reboot | Install the provisioning package, copy the agent + scripts to C:\CloudiwaySetup, create scheduled tasks, uninstall the MSI, reboot. |
| 4 | Force Entra Join | After 1st reboot (SYSTEM) | dsregcmd /join until the device is Azure AD Joined to the target. |
| 5 | Migrate your profile | After 1st reboot (SYSTEM) | Copy your profile from the old SID to the new SID, fix permissions, then reboot again. |
| 6 | Register in target tenant | After you log in | Register the device with the target tenant (Autopilot/Intune), back up BitLocker, finish. |
Phase 1 — Pre-flight & prep
The job opens with a banner line that records the agent version, then validates itself before touching anything destructive. If any required file is missing, it stops here — leaving your PC untouched and still joined to the old tenant — so a half-installed agent can never strand the machine.
| Log line | Plain-English meaning | |
|---|---|---|
Start Migration Job - Agent Version 2026.6.16.1 | ℹ | The migration has begun. The version number identifies which build of the agent is running — useful for support. |
Step : Local admin account created successfully | ✔ | A temporary local administrator (CloudiwayMigration) was created. It lets the migration keep working across reboots even before you can sign in with your new account. It is automatically deleted at the end. |
Step : Local admin account cannot be created - The account already exists. | ⚠ | Harmless. The migration was run a second time (e.g., a retry), and the temporary admin from the first run is still there. The agent simply reuses it. |
Step : CleanupSourceTenant | ℹ | The agent reads the device serial number and hardware ID and calls the Cloudiway platform to remove / prepare the device's record in the source tenant's Intune & Autopilot, and saves migration settings locally for the post-reboot stages. |
Why "Start Migration Job" can appear twice
Phase 2 — Leave the source tenant
Now the device formally leaves the old tenant and the old mobile-device-management (MDM/Intune) footprint is removed so it can't conflict with the new tenant.
| Log line | Plain-English meaning | |
|---|---|---|
Step : UnJoin AAD | ℹ | Runs dsregcmd /leave — disconnects the device from the source Entra ID tenant. |
Step : Cleanup AAD | ℹ | Runs dsregcmd /cleanupaccounts — removes the cached source-tenant work accounts from Windows. |
Step : CleanupAutopilot | ℹ | Removes the old Intune MDM device certificates issued by "Microsoft Intune MDM Device CA". |
Step : Cleanup Autopilot Registry Keys | ℹ | Deletes the old enrollment registry keys and MDM scheduled tasks (Enrollments, EnterpriseResourceManager, PolicyManager, OMADM, …) so the device starts clean for the new tenant. |
Note
UnJoin AAD and Cleanup AAD
each appear in the order the agent runs them; if you see them more than once it is the agent confirming
each sub-step. There is a short, deliberate pause after each dsregcmd
call to let Windows settle.
Phase 3 — Provision & reboot
With the device detached, the agent installs the provisioning package (which seeds the new-tenant join),
copies itself and its helper scripts to C:\CloudiwaySetup,
and registers the scheduled tasks that will run the remaining phases after reboot. Then it removes the
installed MSI and restarts the PC.
| Log line | Plain-English meaning | |
|---|---|---|
Step : InstallProvisioningPackageProvisioning package installed successfully. | ✔ | The migration.ppkg provisioning package was applied. This carries the configuration that lets the device join the target tenant. (The agent also runs shutdown /a to cancel any automatic reboot the package may have queued, so it controls the timing itself.) |
Step : SetupReboot | ℹ | Copies CloudiwayAgent.exe, its DLLs, and the task scripts into C:\CloudiwaySetup, and enables sign-in with a Microsoft 365 account on the lock screen. |
ForceEntraJoin task created successfully. | ✔ | Scheduled task created — will run at boot to join the target tenant. |
RegisterToTargetTenant task created successfully. | ✔ | Scheduled task created — will run after you log in to register the device in the target tenant. |
MigrateProfile task created successfully. | ✔ | Scheduled task created — will run at boot to copy your profile to the new SID. |
…task already existed and was enabled. | ⚠ | Harmless. On a re-run, the task was already present, so the agent just re-enabled it instead of creating a duplicate. |
Step : Uninstall Msi Agent | ℹ | The MSI-installed copy of the agent is removed; the working copy in C:\CloudiwaySetup takes over for the post-reboot phases. |
Step : Reboot | ℹ | The PC restarts. From here, scheduled tasks drive the rest. |
Phase 4 — Force Entra Join
The ForceEntraJoin task runs dsregcmd /join
and then checks the device status every 10 seconds (up to 5 minutes) until Windows reports
AzureAdJoined : YES. Once joined, the task disables itself.
Its activity is written to C:\CloudiwaySetup\ForceEntraJoin.log.
2026-06-16 .. - Starting ForceEntraJoin
2026-06-16 .. - Running dsregcmd /join
2026-06-16 .. - Not yet joined, retry 1/30
2026-06-16 .. - Device is AzureAdJoined: YES
2026-06-16 .. - ForceEntraJoin task disabledSuccess looks like
Device is AzureAdJoined: YES. If instead you see
FAILED: Device did not join within timeout, the device could
not reach Entra ID — check network connectivity and re-run the task.
Phase 5 — Migrate your profile
The MigrateProfile task re-keys your Windows profile from the old SID to
the new SID so your Desktop, Documents, settings, Outlook profile, and OneDrive sync
carry over. It edits the offline copy of your registry hive
(ntuser.dat), re-stamps file ownership/permissions, and
clones the profile entry in the registry.
| Log line | Plain-English meaning | |
|---|---|---|
Migrating profile for [email protected] | ℹ | Profile migration started for this user account. (Other local profiles on the PC are migrated too, one by one.) |
Step : MigrateFilePermissions | ℹ | Re-assigns ownership of the files in the profile folder from the old SID to the new SID, so you keep access after the tenant change. |
Access to the file \\?\C:\Users\…\AppData\Local\Temp\~….TMP is denied. | ⚠ | Expected and safe. A few transient/locked temp files can't be re-permissioned. These are throwaway cache files — the migration skips them and continues. They do not affect your data. |
Step : MigrateProfilePath | ℹ | Begins updating the registry side of the profile (the ProfileList entry and your loaded user hive). |
Start Translating sids in ntuser.dat | ℹ | Walks through your registry hive and rewrites every reference to the old SID so it points to the new SID. |
Start changing permissions in ntuser.dat | ℹ | Updates the access rights inside the hive so the new account owns its own settings. |
Found Root Permission to modify | ℹ | Confirms the agent has the elevated rights it needs to edit protected registry keys. |
Create New SID In registry | ✔ | The profile entry is cloned/registered under the new SID, so Windows associates your profile folder with your new account. |
Step : Reboot | ℹ | Profile work done. The PC reboots again and shows the login screen, where you sign in with your new tenant account. |
This is where you take action
JoinNewAAD ~2 min after sign-in.Phase 6 — Register in target tenant
Once you sign in with the new account, the RegisterToTargetTenant / CloudiwayLogin task finishes the job: it registers the device with the target tenant (Autopilot/Intune), assigns it, triggers the BitLocker recovery key backup, removes the temporary admin, and marks the migration complete.
| Log line | Plain-English meaning | |
|---|---|---|
Step : RegisterToTargetTenant | ℹ | The agent sends the device's hardware ID to the Cloudiway platform to register it in the target tenant, then waits ~6 minutes for the platform to process it. |
Step : AssignDevice | ℹ | Asks the platform to assign the registered device (group tag, primary user) in the target Intune/Autopilot. |
JoinNewAAD : An error occurred in RegisterToTargetTenant : Error AssignDevice : StatusCode : InternalServerError, Reason : Internal Server Error | ✖ | Server-side error (HTTP 500) during device assignment. The local device migration succeeded, but the platform's AssignDevice call failed. See Errors & warnings below — this usually needs a retry or an admin check on the platform, even though the agent reports completion. |
Migration completed | ✔ | The agent finished all on-device work, backed up BitLocker, cleaned up, set the status to MigrationCompleted, and reported it to the platform. |
Why "completed" appears even after the AssignDevice error
Quietly in the background after this
- •BackupBitLockerKey task — backs up the BitLocker recovery key to the new Entra ID, retrying every minute for up to an hour, then self-disables on success.
- •TriggerEnrollment — kicks off MDM/Intune auto-enrollment in the new tenant.
- •The temporary
CloudiwayMigrationadmin is deleted.
10. Reading a real log (top = most recent)
Logs are written newest-first. Read from the bottom up to follow the migration in the order it happened. Here is the captured run, annotated.
Migration completed ← all on-device work done (Phase 6)
JoinNewAAD: An error occurred ... AssignDevice : InternalServerError ← platform 500, logged & survived
Step : AssignDevice ← asked platform to assign the device
Step : RegisterToTargetTenant ← registered device in target tenant
Step : Reboot ← Phase 5 finished, restart to login
Create New SID In registry ← profile cloned to NEW SID ✔
Found Root Permission to modify
Start changing permissions in ntuser.dat
Start Translating sids in ntuser.dat ← re-keying your registry hive
Step : MigrateProfilePath
Access to the file …~….TMP is denied. ← harmless temp-file skip ⚠
Step : MigrateFilePermissions
Migrating profile for [email protected] ← Phase 5 begins
Step : Reboot
Step : Uninstall Msi Agent
ForceEntraJoin task created successfully. ← Phase 3 scheduled tasks
RegisterToTargetTenant task created successfully.
MigrateProfile task created successfully.
Step : InstallProvisioningPackage ← Provisioning package installed ✔
Step : CleanupAutopilot ← Phase 2 cleanup
Step : Cleanup AAD
Step : UnJoin AAD ← left source tenant
Step : CleanupSourceTenant ← Phase 1
Local admin account cannot be created - already exists. ← re-run, harmless ⚠
Start Migration Job - Agent Version 2026.6.16.1 ← run #2
Step : Local admin account created successfully ← run #1 ✔
Start Migration Job - Agent Version 2026.6.16.1 ← START HERE (oldest) ▲11. Errors & warnings explained
⚠ Expected — no action needed
| Message | Why it's safe |
|---|---|
Local admin account cannot be created - The account already exists. | The temporary migration admin already exists from an earlier run. The agent reuses it. |
…task already existed and was enabled. | A scheduled task was already present; the agent re-enabled it instead of duplicating it. |
Access to the file …~….TMP is denied. | Transient/locked temp & cache files can't be re-permissioned. They are disposable — the migration skips them and your real data is unaffected. |
✖ Needs attention
AssignDevice — InternalServerError (HTTP 500)
JoinNewAAD : An error occurred in RegisterToTargetTenant : Error AssignDevice : StatusCode : InternalServerError, Reason : Internal Server Error
What it means: the device finished migrating locally and was registered, but the Cloudiway platform's AssignDevice step (which assigns the device — group tag / primary user — in the target tenant's Intune & Autopilot) returned a server-side error. The agent caught it, logged it, and continued to Migration completed.
Impact: the PC is migrated and usable on the new tenant, but the device may not yet be correctly assigned in the target Intune/Autopilot, so Intune policies / the assigned primary user may be missing until the assignment is fixed.
What to do:
- Confirm the device shows as Azure AD Joined to the target (
dsregcmd /status→AzureAdJoined : YES). - In the Cloudiway platform, re-run / retry the device registration job for this device — a 500 is typically a transient platform error.
- If it persists, verify in the target tenant's Intune/Autopilot that the device's hardware hash imported correctly, and contact Cloudiway support with the agent version (
2026.6.16.1) and the device serial number.
Where to find the logs
C:\CloudiwaySetup\
(and to the Windows Event Log under source CloudiwayAgent).
The Entra-join attempts are in C:\CloudiwaySetup\ForceEntraJoin.log.
12. FAQ
How many times will my PC reboot?
Typically 2 times: once after provisioning (Phase 3) and once after the profile migration (Phase 5). Let each one complete.
Will I lose my files, Outlook profile, or OneDrive?
No. The profile (including Documents/Desktop, Outlook profile, and OneDrive sync configuration) is migrated to your new account's SID. You sign back in and find things in place. Outlook may re-prompt for the new account, and OneDrive may re-sync.
Which account do I sign in with after migration?
Your target tenant (new company) Microsoft 365 / Entra ID account, on the normal Windows login screen.
What is the "CloudiwayMigration" account I might see?
A temporary local administrator the agent uses to keep working across reboots before you can log in with the new account. It is deleted automatically at the end of the migration.
The log says "Migration completed" but I saw a red error — am I fine?
The device is migrated and usable. The red AssignDevice error is a platform-side assignment failure that an administrator should retry (see section 11). It does not mean your data or local migration failed.
Is BitLocker still protecting my disk?
Yes. After you log in, a background task backs up your BitLocker recovery key to the new Entra ID, retrying for up to an hour until it succeeds.