Moving user profiles from domain to domain has often been the topic of conversation. I’ve even written an article that took me more than a year to compile about the very act of copying or moving profiles. Now, we have Active Directory in Office 365 and Azure (Or Entra ID or whatever they’re calling it) to contend with. Many small businesses are going to want to move users from an on-premises directory to Azure AD, and that’s what I’ll be talking about today.

I should note that this process was adapted from moving a group of six users from a local Active Directory setup (on-premise) to remote workers, and then eventually permanently remote in Azure AD. These users are currently licensed on 365 as “Microsoft 365 Business Premium.” I expect these to change as well as the licensing requirements for access to these features. Profwiz is a free tool available from ForensIT and is used in the examples I describe.

Before you start this process, make sure you have a solid backup, whatever format that takes. Backup everything. These changes will be fairly drastic, so backup, backup. Let’s go.

I do all of the following on the same network as the AD domain controller; it’s best to remove the machine from the AD domain cleanly. All of this, of course, is dependent on the Professional or Enterprise version of Windows 10 and higher. If you’re using the “Home” version, you’re doing something else entirely (because it can’t join to an AD domain).

Also some important caveats. You probably know many of these or you wouldn’t have planned to move to Azure AD in the first place, but they’re worth mentioning. The first is lack of GPO support, so if you’re managed machines, mapping local files shares, etc etc, you’ll be disappointed. Make sure that local file share access is not a requirement. In some cases I’ve managed to get business apps working with Sharepoint Online, others might not. A local SQL server may be a challenge too. I generally do this migration for users that are permanently leaving behind ties to a local AD server. All of these considerations are, of course, beyond the full scope of this how-to.

These are the steps I follow to migrate machines:

1. Create / Correct / Enable / Admin Local user (Owner) account

In this step, I’m mindful of having an account I can use as a backup. Create that account, leave it passwordless and make it a local admin.

2. Run Profwiz to migrate Domain account to local account (Restart. Log in as this user on boot)

This requires the use of the local machine name and manually typing in the account name. I keep it to “Owner” for ease of use and to avoid the default administrator account. When logging in, disregard any errors, etc. These will be corrected later.

3. Detach from the domain in “sysdm.cpl” (Restart the computer)

This one’s best when you’re able to connect to the domain controller. For the workgroup, it’s an empty field. Just use the historical default of “WORKGROUP.”

4. Join the machine to Azure AD

Find this on Windows 10+ in Settings -> Accounts -> Access Work or School -> Connect -> Join This Device to Azure AD. You might get an enrollment error “code 8018000a” here – if that’s the case, use this Powershell script to remove accounts in the settings. This became so common, that I started just doing this before getting the error. I also remove personal accounts from the accounts.live.com, devices tab. Also, if you need to, run Credential Manager “rundll32.exe keymgr.dll, KRShowKeyMgr” to remove any links to personal or unneeded logins there. If there are any removals here, I suggest rebooting again.

5. Log out, Log in as ‘Other User’, and use the target user’s email address as the username

There were cases where the login screen didn’t have an “Other User” option and I recall enabling that with a group policy. Generally, this option will be visible as long as Windows has multiple account options. Even though you’ve joined the Azure AD domain, you’ll have to type the user’s full email address manually. Also, this will load a blank profile. Don’t panic. You might also go through a verification two-factor process, so be prepared with a phone or some means of undertaking that.

6. Then, use Profwiz to migrate the local account (Owner in my above example) to your @domain.com 365 account (Restart the computer)

Yes, this feels like the most awkward part of the process – but you’re almost there. Write out the user’s domain ‘domain.com’ and select “AzureAD. Disable “Join Domain. Then, enter the account name as the full email address. After the restart, log in as the 365 User again and the original profile will load. When it finishes, you can update and correct any small issues before handing the device to the user. Several services may need to be logged in or reinstalled.

Finally

Depending on the number of computers you’re working through, the most immediate step should be to check on whether this new device is fully attached to Azure AD. I do this by logging into the Entra ID Admin Portal and looking for Azure Active Directory -> Devices -> All Devices (no doubt Microsoft will screw with this menu progression). Here, find the computer name and under “Join Type” you should see “Azure AD joined.” Thinking of this process, I sense it could also be applicable to 365 tenant to 365 tenant migrations that will no doubt be needed in the future. There’s also a process to save accounts with ForensIT’s script – it’s a one-time process and re-usable on further machines, but I find it isn’t required unless you’re using a non-free version of Profwiz to actually add Windows machines to Azure AD (you do this in Windows in step 4).