Field note: MFA blocked our mailbox migration tool, and a one-letter typo did the rest

A small business was joining a partner company, and its email had to move from its own Microsoft 365 tenant into the partner’s. It was a small job: six user mailboxes, a pile of distribution groups, and two email domains that needed to move with them. We used BitTitan MigrationWiz to copy the mailboxes. Two things slowed us down, and both are easy to avoid next time.

What it looked like

When we set up the project, MigrationWiz couldn’t connect to either tenant. The source and the destination both failed with modern authentication errors. The credentials were right, and the accounts worked fine in a browser.

What was actually wrong

The admin accounts MigrationWiz was signing in with had MFA turned on. A migration tool signs in on its own in the background, so there’s nobody there to tap “approve” or type the number from the Authenticator app. The sign-in just fails.

The fix is to exclude the migration accounts from the Conditional Access policy that requires MFA, on both tenants, for the length of the migration. Two things tripped me up:

• Excluding the accounts one by one didn’t get me there. So I made a temporary group with an obvious name, put the migration accounts in it, and excluded the group. A group is also easier to clean up: delete it when you’re done and the exclusion goes with it.
• I was still getting number-match prompts after excluding myself. That usually means a different policy is the one enforcing MFA. The fastest way to find it is the sign-in log. Open the failed or prompted sign-in in Entra ID, go to the Conditional Access tab, and it shows exactly which policy applied.

Once the right policy had the exclusion, both connections went green.

The second snag: a one-letter typo

Four of the six mailboxes passed MigrationWiz’s verification. The other two failed. Their destination addresses had the domain spelled with one wrong letter, and that’s easy to miss when you’re reading a column of almost-identical addresses. After I fixed the mapping, all six verified and started migrating.

The rest of the move

A few other decisions mattered more than the tool did:

• Decide which addresses move with the domain. Some mailboxes used an address on a domain that wasn’t moving. Those had to be changed to the moving domain before cutover, or they’d have had nowhere to land.
• Distribution groups don’t come along on their own. We exported them from the source tenant and recreated them in the destination.
• Domains move last. A domain can only be verified in one tenant at a time, so it comes out of the old tenant and gets verified in the new one at cutover. Then the mail DNS records (MX, SPF, DKIM, autodiscover) get updated.

What I took away from it

• Plan the MFA exclusion for migration accounts before you start. Make it temporary, keep it narrow, and remove it when you’re done. A forgotten MFA bypass is a real risk.
• A temporary, clearly named group makes the exclusion easy to add and easy to remove.
• When MFA keeps prompting after you’ve excluded someone, check the sign-in log’s Conditional Access tab before guessing.
• Check address mappings character by character before you run verification.
• Work out early which addresses are moving and which domains are staying. It changes the whole plan.