If you configure a MigrationWiz project for administrator migration when the source tenant will not support that access model, the project may not even be able to start. MigrationWiz provides two authentication models for M365 source endpoints, and the right choice depends on what permissions you can actually obtain in the source tenant.

With administrator migration, MigrationWiz uses a single service account with ApplicationImpersonation scoped at the organization level to reach all source mailboxes. That approach is typical for enterprise environments where IT controls the tenant and can set RBAC and impersonation.

Delegated migration works differently: each mailbox is accessed using individual user credentials. This model is common when the source tenant belongs to an external organization that will not grant admin-level access, something you see frequently in acquisition migrations before IT integration is complete and before administrative handoff has occurred.

In acquisitions, early phases sometimes came with limited administrative access to the source tenant. In those scenarios, selecting the correct authentication model based on the access you truly have is the decision that determines whether the MigrationWiz project can launch.

Because delegated migration requires collecting credentials from individual source users, that collection process needs to be scheduled and built into pre-migration planning before the project is created.

Is your MigrationWiz project set up for administrator migration or delegated migration, and does that align with the RBAC access you actually have in the source tenant?

#BitTitan #MigrationWiz