Authentication and permission management for Microsoft 365 can be complex and varies by type. This article covers the various types of authentication, what scenarios they apply to, and special cases.
The specific authentication needed and the steps to enable it will be found in the migration guide for your specific scenario.
Keep in mind that BitTitan only supports Modern Authentication for Microsoft 365 endpoints used for Mailbox, Online Archive mailbox, and Public Folder migrations. Modern Authentication provides a more secure authentication mechanism for registered applications to connect to Microsoft Entra ID and Microsoft 365.
Microsoft's documentation explains enabling and disabling Modern Authentication for Exchange Online.
Please review the documentation below for a better understanding of the authentication methods for:
But first, let's review the terminology and the authentications available.
Basic Authentication is no longer supported between MigrationWiz and Exchange Online endpoints as of the end of December 2022 due to Microsoft discontinuing support for Basic Authentication in Exchange Online. Basic Authentication will not be supported after that and configuring MigrationWiz to use Modern Authentication will be required.
Modern authentication is based on the use of OAuth 2.0 tokens and the Active Directory Authentication Library. It notably adds support for multifactor authentication, in which a secondary challenge besides a password is used to verify a user's identity, such as previously set personal questions.
With Delegated Permissions, your application needs to access the web API as the signed-in user, but the selected permissions limit access. A user can grant this type of permission unless the permission is configured as requiring administrator consent.
With Application Permissions, your application needs to access the web API directly as itself (no user context). This type of permission requires administrator consent and is also not available for native client applications.
Modern Authentication - Delegated Permissions
- Created in the customer's Microsoft Entra account.
- Requires admin credentials.
Modern Authentication - Delegated Permissions - BitTitan App
This authentication method requires the BitTitan permissions app. The steps for this app are described in the following section.
Global admin credentials are required for this method.
- SharePoint migrations: Site Collection admin credentials
- OneDrive migrations: will utilize the SharePoint admin credentials. The admin will be promoted to a site collection admin for the OneDrive account being migrated. OneDrive user account provisioning is supported when using SharePoint admin credentials (provided the destination tenant doesn’t block basic authentication).
Modern Authentication - Application Permissions - BitTitan App
This authentication method requires the BitTitan permissions app. The steps for this app are described in the following section.
- This method uses user credentials, but the user will need to be a member of a created MigrationWiz security group in the Microsoft 365 tenant.
- Global admin permissions are required to give consent to the BitTitan app.
- OneDrive provisioning is not supported and only admin cred flow is supported.
- Requires the Advanced Option UseApplicationPermission=1
Modern Authentication - Delegated Permissions - BitTitan App
This authentication method requires the BitTitan permissions app. The steps for this app are described in the Teams to Teams migration guide.
- Requires global admin or Teams admin credentials.
- Requires the Advanced Option UseDelegatePermission=1
Modern Authentication - Application Permissions - BitTitan App
This authentication method requires the BitTitan permissions app. The steps for this app are described in the Teams to Teams migration guide.
- This method uses user credentials, but the user will need to be a member of a created MigrationWiz security group in the Microsoft 365 tenant.
Document migrations in the Microsoft 365 Small Business Tenant require some special considerations.
MigrationWiz supports Document Migration, but the Destination has to be configured in the following manner:
While the Source (e.g., Google Drive) can use admin credentials, the Destination, Microsoft 365 Small Business Tenant, must be configured with the end user credentials. If admin credentials are used, the following error arises:
Destination: Your migration failed to check destination credentials. One Drive for Business administrative authentication failed with <your tenant URL>.
We use SharePoint administrator API to perform auto-provisioning and provide the administrator rights to access user sites. Some Office 365 plans prevent us from accessing them (Small Business, for example). If your plan does not provide access to the SharePoint administrator API, you must use your end-user credentials.
Microsoft 365
Below you can find the information related to Microsoft 365 Mailbox, Online Archive mailbox, and Public Folder migrations, and suggested:
- Meet the prerequisites
- Check your endpoints
- Register and configure your application
- Set up Microsoft Entra SSO for MigrationWiz
Meet the Prerequisites
Before beginning your migration process please ensure to meet the following prerequisites:
- A Global Administrator account with access to Microsoft Entra ID.
- MigrationWiz Mailbox project(s) created and ready for configuration.
- End-user credentials are not supported. Administrator credentials must be used for the endpoints in the MigrationWiz project
- The application will require administrator consent.
Warning
App password usage, MFA/2FA, and ADFS are not supported for the migration admin account/service account being used by these endpoints. The administrator account will need to be excluded from these policies if enabled.Check your Endpoints
To check the supported endpoints for each Microsoft 365 project type, please click the dropdown below and take a look.
| Project Type | Source | Destination |
| Mailbox |
|
|
| Public Folder |
|
|
| Personal Archive |
|
|
| Hybrid | On-Premises Exchange 2010+ | Microsoft 365 (Hybrid Migrations only) |
Register and Configure your Application
Below, you can find a series of tabs that outline the necessary steps for setting up the tenant, registering the application, and assigning permissions.
Each tab contains four or three main steps specific to each migration type. Please follow them carefully to ensure a smooth process.
Deprecation of Microsoft Application Impersonation Role
From February 2025, Microsoft has started the depreciation process to remove the Application Impersonation role from O365. Exchange On-premise and Hosted Exchange are not affected by these changes. For further information please see this article.
If you are currently using Application Impersonation for your migrations, there is no telling when that will eventually fail. It is highly recommended that you switch to using the new API permission process to avoid delays in your project due to permission failures.
The information below outlines different processes to prepare your environment using API permission or Delegated permission.
Even though delegated permissions are an option, are not recommended. Instead, we strongly recommend using the approach from the General API Permissions tab.
In case you want further information for Mailbox and Personal Archive endpoints we strongly recommend you to check the approach outlined in the Performing Migration using only API permissions article.
Step One - Create a New Application Registration
Create a new Application Registration in the Microsoft 365 tenant source or destination.
- Log in to the Microsoft Entra admin center with a Global Administrator login.
- Click View all products and select Microsoft ID (Azure AD) in the Microsoft Entra Admin Center.
- In the left sidebar, open the Applications dropdown list and select App Registrations, which is found under the Identity dropdown list.
- Select New Registration at the top of the screen.
- Give the app a distinct name. You can change this later if necessary.
- Select the Accounts in this organizational directory only ('Tenant name only' - Single tenant) radio button.
- Click Register.
- Under the Manage menu, select Authentication.
- Set the option Allow public client flows to Yes.
- Click Save.
Step Two - Assign the API Permissions and Grant Admin Consent
The following steps allow you to assign the API permission and grant consent to the necessary M365 components.
- From the Manage menu, select API permissions.
Important
If an API permission is named User.Read under Microsoft Graph is already present, this can be removed. The Microsoft Graph API does not apply to this project type and is not used. - Click Add a Permission.
- Select APIs my organization uses.
- Scroll down or search for the following permissions Office 365 Exchange Online.
- Select Delegated Permissions.
- Select EWS.
- Check the box under EWS for EWS.AccessAsUser.All.
Important
This permission only allows the OAuth application (MigrationWiz) to be associated with EWS. This does not grant access to all mailbox data. - Click Add a Permission.
- Select APIs my organization uses.
- Scroll down or search for the Office 365 Exchange Online.
- Select Application Permissions.
- Check the box under Other Permissions for full_access_as_app.
- Click Add Permissions.
- Click Grant admin consent.
- Click Yes to confirm the settings. Under the Status column, you should see a message that permission has been granted for the domain.
Step Three - Obtain the AppID and TenantID from the Application Registration
Follow the steps below to obtain the AppID and TenantID from the Application Registration.
- Navigate to the App Registrations item as shown below. In the Overview tab, you will find the Application (client) ID and the Directory (Tenant) ID.
- Copy both of these to another application, such as Notepad, for use later in this process. This is needed for the MigrationWiz Project Setup.
Step Four - Create a Client Secret
Create a Client Secret for the application by following the steps below.
- Go to Manage > Certificates & secrets from the left sidebar.
- Create a new secret client by clicking + New client secret.
- Copy and save the client secrets' value on a notepad or other preferred tool.
Warning
Consider that the secret client's value is only available until the first time you sign off the Azure Portal after the secret client creation. After that, it will be no longer visible.In case you lost the value, please create a new client secret as suggested above and use it in the steps below.
Some migrations may require only allowing rights to the migration process for a particular set of users. In such cases, use the following procedure that outlines how this can be achieved. To do so, please replace Step Two's instructions from the General API Permissions tab with the ones detailed below.
Replacement Step Two - Changes in API Permissions
In Step Two you must add the additional Application Permissions to the App Registration. In this case, the full_access_as_app permission should NOT be checked.
When this permission is selected, it will override any of the management scopes and simply provide access to all mailboxes in the organization. So, remove this permission if you had previously included it in your application registration.
Create Management Scope Manually Using a Mail-Enabled Security Group
To assign a management scope only for a particular set of mailboxes, create a mail-enabled security group in the tenant (or use an existing one).
Make sure you have copied down the distinguished name of the security group as you will need it when creating the restriction filter for your management scope. The following is an example of what a distinguished name for the group would look like:
CN=MailEnSecGro20240913485729,OU=BTTest.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMP210A006,DC=PROD,DC=OUTLOOK,DC=COM
To obtain the Distinguished Name of a Group, you can use the PowerShell command below. It does rely on the connection made into the Exchange Online module so be sure to connect there first.
Connect-ExchangeOnline
Get-distributiongroup -identity "GROUPNAME" | select distinguishedname | fl
Then follow the steps below to create the management scope.
- Connect to the M365 Tenant with the following PowerShell command, using your Admin credentials.
connect-exchangeonline - Run these PowerShell commands, replacing the items in bold with the details from your Enterprise Application, and make sure to use the distinguished name of your own security group and not the one in the example shown below:
$applicationId = "ApplicationID from the Enterprise Application"
$objectId ="ObjectID from the Enterprise Application"
$MgmtScopeName="User Mailboxes"
New-ManagementScope -Name $MgmtScopeName -RecipientRestrictionFilter "MemberOfGroup -eq 'CN=MailEnSecGro20240913485729,OU=BTTest.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=NAMP210A006,DC=PROD,DC=OUTLOOK,DC=COM'"
New-ServicePrincipal -AppId $applicationId -ObjectId $objectid -DisplayName "MigrationWiz"
New-ManagementRoleAssignment -App $objectId -Role "Application EWS.AccessAsApp" -CustomResourceScope $MgmtScopeName - Check that the management scope is in place by using this command.
Get-ManagementScopeThe results will have a similar output to this image.
In the example above, only mailboxes that are members of the mail-enabled security used for the recipient restriction filter will be in scope for the migration.
As a result, when you try to perform a migration with MigrationWiz, mailboxes that are not added as members of the mail-enabled security group will fail with a 403 error like in the following example.
Your migration failed while checking destination credentials. The request failed. The remote server returned an error: (403) Forbidden.
In the example above, the destination mailbox fails as it is not a member of the mail-enabled security group being used for the management scope in the destination tenant.
Another way to confirm that a mailbox is part of the scope created is by running the following PowerShell commands against the impacted mailbox in the tenant.
Test-ServicePrincipalAuthorization -Identity <ObjectID, AppID, or DisplayName> [-Resource] <target mailbox>
Tip
The ObjectID or AppID refers to the same values used to create the management scope earlier
As a result, you will get the following values:
- InScope = False, indicating the mailbox is not a member of the mail-enabled security group used for the management scope.
- InScope = True, indicating the mailbox is a member of the mail-enabled security group.
The DisplayName of the Service Principal is used in the example below, showing an InScope value of False.
Updating the Management Scope
To update the management scope, you must remove the previous one and re-apply it to the tenant. To do this, follow the next steps:
- Remove the Management Role Assignment.
get-managementroleassignment -Identity "Application EWS.AccessAsApp*" -RoleAssigneeType ServicePrincipal | remove-managementroleassignment - Remove the Service Principal.
remove-serviceprincipal -identity "MigrationWiz" - Remove the Management Scope itself.
remove-managementscope -identity "User Mailboxes"
Afterward, you can rerun the commands from the sections above to recreate the Management Scope with the updated filter.
In case you want to use delegated permissions, follow the steps below. Keep in mind that we do not recommend this approach due to performance porpuses.
As you may know, having administrative access to the Microsoft 365 control panel to manage users does not necessarily mean that the same account has permission to access all mailboxes for migration. In order to have administrative permissions to migrate mailbox data, it is necessary to grant the account permissions on each mailbox.
Below you can find a PowerShell example to manually grant administrative access for migration. In case you want to perform it through the Exchange Admin Center you can follow the steps provided by Microsoft here.
$LiveCred = Get-Credential
Install-Module -Name ExchangeOnlineManagement
Import-Module -Name ExchangeOnlineManagement
Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred
Get-Mailbox -ResultSize Unlimited | Add-MailboxPermission -AccessRights FullAccess -Automapping $false -User MigrationWiz
The above command must be applied each time a new mailbox is created, as permissions are set directly on the mailbox. The administrative account will not have access until the permissions are applied.
The global admin account does have the necessary rights for delegation. However, again, we recommend using API permissions for migrations from and/or to Microsoft 365.
If connecting to GCC High with Powershell, use:
Connect-ExchangeOnline -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -ExchangeEnvironmentName O365USGovGCCHigh
This is the approach for Public Folder migrations.
Step One - Create a New Application Registration
Create a new Application Registration in the Microsoft 365 tenant source or destination.
- Log in to the Microsoft Entra admin center with a Global Administrator login.
- Click View all products and select Microsoft ID (Azure AD) in the Microsoft Entra Admin Center.
- In the left sidebar, open the Applications dropdown list and select App Registrations, which is found under the Identity dropdown list.
- Select New Registration at the top of the screen.
- Give the app a distinct name. You can change this later if necessary.
- Select the Accounts in this organizational directory only ('Tenant name only' - Single tenant) radio button.
- Under Redirect URI (optional), select Public client/native (mobile & desktop) and set it to urn:ietf:wg:oauth:2.0:oob
- Click Register.
- Under the Manage menu, select Authentication.
- Set the option Allow public client flows to Yes.
- Click Save.
Step Two - Assign the API Permissions and Grant Admin Consent
The following steps allow you to assign the API permission and grant consent to the necessary M365 components.
- From the Manage menu, select API permissions.
Important
If an API permission is named User.Read under Microsoft Graph is already present, this can be removed. The Microsoft Graph API does not apply to this project type and is not used. - Click Add a Permission.
- Select APIs my organization uses.
- Scroll down or search for the following permissions Office 365 Exchange Online.
- Select Delegated Permissions.
- Select EWS.
- Check the box under EWS for EWS.AccessAsUser.All.
Important
This permission only allows the OAuth application (MigrationWiz) to be associated with EWS. This does not grant access to all mailbox data. - Click Add Permissions.
- Click Grant admin consent.
- Click Yes to confirm the settings. Under the Status column, you should see a message that permission has been granted for the domain.
Step Three - Obtain the AppID and TenantID from the Application Registration
Follow the steps below to obtain the AppID and TenantID from the Application Registration.
- Navigate to the App Registrations item as shown below. In the Overview tab, you will find the Application (client) ID and the Directory (Tenant) ID.
- Copy both of these to another application, such as Notepad, for use later in this process. This is needed for the MigrationWiz Project Setup.
If you want to set up a Microsoft 365 Groups endpoint please consider the following recommendations before setting up your API permissions as suggested in steps below.
- Configuration without ModernAuthClientSecret: Avoid using ModernAuthClientSecret in the advanced options. Instead, use ClientId, TenantId, and Global/Exchange Admin credentials.
- Connector User Ownership: Ensure that the connector user is the owner of the Microsoft 365 Group being migrated.
- Utilize Recipient Mappings: Implement recipient mappings for mapping user attributes during the migration. For more information, please check the recipient mapping section of the Advanced Options and General Options article.
Please use this approach for Microsoft 365 Groups migration endpoints, taking into account the information provided above.
Step One - Create a New Application Registration
Create a new Application Registration in the Microsoft 365 tenant source or destination.
- Log in to the Microsoft Entra admin center with a Global Administrator login.
- Click View all products and select Microsoft ID (Azure AD) in the Microsoft Entra Admin Center.
- In the left sidebar, open the Applications dropdown list and select App Registrations, which is found under the Identity dropdown list.
- Select New Registration at the top of the screen.
- Give the app a distinct name. You can change this later if necessary.
- Select the Accounts in this organizational directory only ('Tenant name only' - Single tenant) radio button.
- Under Redirect URI (optional), select Public client/native (mobile & desktop) and set it to urn:ietf:wg:oauth:2.0:oob
- Click Register.
- Under the Manage menu, select Authentication.
- Set the option Allow public client flows to Yes.
- Click Save.
Step Two - Assign the API Permissions and Grant Admin Consent
The following steps allow you to assign the API permission and grant consent to the necessary M365 components.
- From the Manage menu, select API permissions.
Important
If an API permission is named User.Read under Microsoft Graph is already present, this can be removed. The Microsoft Graph API does not apply to this project type and is not used. - Click Add a Permission.
- Select APIs my organization uses.
- Scroll down or search for the following permissions Office 365 Exchange Online.
- Select Delegated Permissions.
- Select EWS.
- Check the box under EWS for EWS.AccessAsUser.All.
Important
This permission only allows the OAuth application (MigrationWiz) to be associated with EWS. This does not grant access to all mailbox data. - Click Add Permissions.
- Click Grant admin consent.
- Click Yes to confirm the settings. Under the Status column, you should see a message that permission has been granted for the domain.
Step Three - Obtain the AppID and TenantID from the Application Registration
Follow the steps below to obtain the AppID and TenantID from the Application Registration.
- Navigate to the App Registrations item as shown below. In the Overview tab, you will find the Application (client) ID and the Directory (Tenant) ID.
- Copy both of these to another application, such as Notepad, for use later in this process. This is needed for the MigrationWiz Project Setup.
Important
Please note that for Google Groups to Shared Mailbox, a Global Admin is required for the destination if you wish to migrate members.This is the approach for Google Groups to Microsoft 365 migrations.
Step One - Create a New Application Registration
Create a new Application Registration in the Microsoft 365 tenant source or destination.
- Log in to the Microsoft Entra admin center with a Global Administrator login.
- Click View all products and select Microsoft ID (Azure AD) in the Microsoft Entra Admin Center.
- In the left sidebar, open the Applications dropdown list and select App Registrations, which is found under the Identity dropdown list.
- Select New Registration at the top of the screen.
- Give the app a distinct name. You can change this later if necessary.
- Select the Accounts in this organizational directory only ('Tenant name only' - Single tenant) radio button.
- Under Redirect URI (optional), select Public client/native (mobile & desktop) and set it to urn:ietf:wg:oauth:2.0:oob
- Click Register.
- Under the Manage menu, select Authentication.
- Set the option Allow public client flows to Yes.
- Click Save.
Step Two - Assign the API Permissions and Grant Admin Consent
The following steps allow you to assign the API permission and grant consent to the necessary M365 components.
- From the Manage menu, select API permissions.
Important
If an API permission is named User.Read under Microsoft Graph is already present, this can be removed. The Microsoft Graph API does not apply to this project type and is not used. - Click Add a Permission.
- Select APIs my organization uses.
- Scroll down or search for the following permissions Office 365 Exchange Online.
- Select Delegated Permissions.
- Select EWS.
- Check the box under EWS for EWS.AccessAsUser.All.
Important
This permission only allows the OAuth application (MigrationWiz) to be associated with EWS. This does not grant access to all mailbox data. - Click Add Permissions.
- Repeat steps 2 and 3.
- Search Microsoft Graph.
- Then select Delegated Permissions.
- Select permissions below and click Add Permissions.
- Directory.ReadWrite.All
- Group.ReadWrite.All
- GroupMember.ReadWrite.All
- User.Read.All
- Click Grant admin consent.
- Click Yes to confirm the settings. Under the Status column, you should see a message that permission has been granted for the domain.
Step Three - Obtain the AppID and TenantID from the Application Registration
Follow the steps below to obtain the AppID and TenantID from the Application Registration.
- Navigate to the App Registrations item as shown below. In the Overview tab, you will find the Application (client) ID and the Directory (Tenant) ID.
- Copy both of these to another application, such as Notepad, for use later in this process. This is needed for the MigrationWiz Project Setup.
Once you create a MigrationWiz project, do not forget to use the credentials you used here. These are required when setting up your endpoints (source and destination).
Warning
Please consider that you will not be able to save your project if you do not complete these fields, the credentials (client or tenant) are incorrect, or the credentials do not belong to the tenant.
Besides, remember that the client secret field is only mandatory for mailbox and archive endpoints.
Common Errors when Configuring Your Endpoint
For more information, review the AADSTS700016, AADSTS90002, and ADDSTS50126 issues on the Common Errors Using Modern Authentication page.
Make sure to complete the Application (client) ID and the Directory (tenant) ID fields, otherwise, the following warnings arise and you cannot go to the next step.
This happens when configuring the source or destination endpoints.
Invalid Application Client ID at Source Settings
Check whether the Application ID has been installed before or if it is the right one. For more information, refer to AADSTS700016.
Invalid Directory Tenant ID at Source Settings
Check whether the Directory Tenant ID has been installed before or if it is the right one. For more information, refer to AADSTS90002.
In case an Invalid Username or Password at source settings or client settings occurs a warning arises. Make sure that your credentials are the correct ones.
For more information, refer to ADDSTS50126.
Set up Microsoft Entra SSO for MigrationWiz
Our Support team can enable the Microsoft 365 Microsoft Entra login on your company's MigrationWiz account. Note that SSO login happens at the domain level, which means all users with the domain you request will therefore be required to sign in with their Microsoft 365 Microsoft Entra logins - for example, instead of enabling SS just for You@company.com, it would be enabled for all users of @company.com.
To set this up, you must have at least one MigrationWiz account with the same domain as your Microsoft 365 account. We do not support other SSO providers at this time.
- Contact our Support team.
- Our support team will set up your account to use Microsoft Entra login.
- Once your Microsoft Entra is ready, Support will contact you with instructions.
- You will receive a response from Support when your account is all setup.
If any Security Conditional Access Policy at Microsoft Entra is blocking the BitTitan Application for MigrationWiz SSO then Exclude the application for the SSO to work.
To use the MigrationWiz PowerShell SDK with MigrationWiz SSO, you must use your original MigrationWiz/MSPComplete password, not your Microsoft Entra password.
SharePoint and OneDrive
Warning
App password usage, MFA/2FA, and ADFS are not supported for the migration admin account/service account being used by this endpoint.MigrationWiz now supports read-only Application Permissions for SharePoint and OneDrive migrations, introducing the UseApplicationPermission=1 option alongside FullControl permissions. This new read-only permission app can only be used at the source to enhance security, while destination permissions will always require FullControl access.
This allows for a secure migration without Global Admin or Site Collection Admin permissions on the source and destination.
This app is similar to the Office 365 Authentication App previously deployed, which utilized delegate permissions. This app uses application permissions.
Microsoft has fully verified and accepted BitTitan applications.
Your Granted Permissions
Before enabling your application permissions, let's check the permissions granted in each case:
The following permissions are granted for Read Only.
SharePoint API
- Sites.Read.All
- User.Read.All
Graph API
- Directory.Read.All
- Files.Read.All
- Group.Read.All (delegate permission)
- User.Read (delegate permission)
The following permissions are granted for Full Control.
SharePoint API
- Sites.FullControl.All
- User.ReadWrite.All
Graph API
- Directory.Read.All
- Files.Read.All
- Group.Read.All (delegate permission)
- User.Read (delegate permission)
Enable your Application Permissions
When you enable your application permissions, you'll see a message like the one below, depending on the permission you choose.
Depending on your endpoint, these permissions must be enabled at the source or destination. Please follow the steps below to enable them.
These are the steps to enable permission level at the source only. This authentication process gives you control over who is entitled to use the source.
- Ensure you are signed in as a Global Admin.
- Go to either MigrationWiz-SharePoint-ReadOnly or MigrationWiz-SharePoint-FullControl and consent to the app access when prompted.
- Create a new Security Group named “MigrationWiz” on the Office 365 Admin Portal.
- Create a new user. This user must have a SharePoint/OneDrive license applied.
- Add a new user to the previously created security group as a member.
- Create MigrationWiz project.
- When creating the endpoints, enter the new user credentials.
- Add support option UseApplicationPermission=1
The following steps enable permission level at the destination.
- Ensure you are signed in as a Global Admin.
- Go to MigrationWiz-SharePoint-FullControl and consent to the app access when prompted.
- Create a new Security Group named “MigrationWiz” on the Microsoft 365 Admin Portal.
- Create a new user. This user must have a SharePoint/OneDrive license applied.
- Add a new user to the previously created security group as a member.
- Create MigrationWiz project.
- When creating the endpoints, enter the new user credentials.
MigrationWiz-SharePoint-FullControl may be used on both source and destination tenants and will export document permissions. MigrationWiz-SharePoint-ReadOnly can only be used on the source tenant, will not export document permissions, and cannot use AMR.
Post-Migration Steps
- Remove the newly created user.
- Remove the MigrationWiz Security Group created in Step 3.
To remove the app from the source or destination, perform the following steps:
- Sign in to Microsoft Entra admin center.
- Select Microsoft Entra ID.
- Go to Identity > Applications > Enterprise applications, in the left bar of the window.
- In the Manage section, select All applications.
- Search for the application permission you configured in step 2 (MigrationWiz-SharePoint-ReadOnly or MigrationWiz-SharePoint-FullControl ) and select it.
- Go to Manage > Properties, and select Delete from the properties bar.
Microsoft Teams
Keep in mind that this section only is applicable for Teams - Global admin & Application Permissions.
Warning
App password usage, MFA/2FA, and ADFS are not supported for the migration admin account/service account being used by this endpoint.In recent updates, the AO UseApplicationPermission=1 has been defaulted. Use Teams-FullControlApp for both Source and Destination.
MigrationWiz now supports read-only Application Permissions for Team migrations, in addition to full-control permissions. This new app, with ReadOnly permissions, can only be used at the source to enhance security and will not export document permissions. The destination permissions will always require FullControl permissions.
This allows for a secure migration without using Global Admin or Site Collection Admin permissions on the source and destination. The account still must be licensed for Teams at Exchange Online tenant.
This app is similar to the Office 365 Authentication App previously deployed, which utilized delegate permissions. This app uses the application permissions. If you are not using application permissions, go to the Authentication App article and follow those steps.
Your Granted Access
Before enabling your application permissions, let's check the permissions granted in each case.
When enabling ReadOnly permissions you will have access to conversations, Teams permissions, and documents. By choosing ReadOnly, the following permissions are granted:
SharePoint API
- Sites.Read.All
- User.Read.All
Graph API
- Files.Read.All
- Group.ReadWrite.All
(This is to add the user to the team as an owner first before being able to read conversations) - User.Read.All
- Group.Read.All (delegate permission)
(This is to be able to read all the conversations as a user after being added) - User.Read (delegate permission)
When enabling FullControl permissions you will have access to conversations, Teams permissions, documents, and document permissions. By choosing FullControl, the following permissions are granted:
SharePoint API
- Sites.FullControl.All
- User.ReadWrite.All
Graph API
- Files.Read.All
- Group.ReadWrite.All
- User.Read.All
- Group.ReadWrite.All (delegate permission)
- User.Read (delegate permission)
Enable Application Permissions
When you enable your application permissions, you'll see a message like the one below, depending on the permission you choose.
-
Ensure you are signed in as a Global Admin in the Office 365 Admin Portal.
-
Go to either Teams-ReadOnlyApp or Teams-FullControlApp and consent to the app access when prompted. If choosing the Teams-ReadOnlyApp option, you will need to disable AMR via "DisableAsynchronousMetadataRead=1", due to Microsoft API limitation.
-
Create a new Security Group named “MigrationWiz” on the Microsoft 365 Admin Portal. If you have not created a security group before, follow Microsoft's instructions.
-
Create a new user. This user must have an active Teams license applied.
-
Add a new user to the previously created security group as a member. Important: ADFS and MFA must be turned off for this user.
-
Create MigrationWiz project.
-
When creating the endpoints, enter the new user credentials.
These are the steps to enable the permissions level at the destination.
-
Ensure you are signed in as a Global Admin.
-
Go to Teams-FullControlApp and consent to the app access when prompted.
-
Create a new Security Group named “MigrationWiz” on the Microsoft 365 Admin Portal.
-
Create a new user. This user must have an active Teams license applied. Important: ADFS and MFA must be turned off for this user.
-
Add a new user to the previously created security group as a member.
-
Create MigrationWiz project.
-
When creating the endpoints, enter the new user credentials.
Teams-FullControlApp may be used on both source and destination tenants and will export document permissions. Teams-ReadOnly can only be used on the source tenant, and will not export document permissions.
Post-Migration Steps
-
Remove the newly created user.
-
Remove the MigrationWiz Security Group created in Step 3.
To remove the app from the source or destination, perform the following steps:
- Sign in to Microsoft Entra admin center.
- Select Microsoft Entra ID.
- Go to Identity > Applications > Enterprise applications, in the left bar of the window.
- In the Manage section, select All applications.
- Search for the application permission you configured in step 2 (Teams-ReadOnlyApp or Teams-FullControlApp) and select it.
- Go to Manage > Properties, and select Delete from the properties bar.