Microsoft service throttling limits the number of concurrent calls to a Microsoft service to prevent overuse of resources. These limits are set by the Microsoft services and are dependent on the service type along with the operations that are being completed by On Demand for the service. In addition, any throttling limits are subject to change by Microsoft.
Microsoft Graph
Microsoft Graph is designed to handle a high volume of requests. If an overwhelming number of requests occurs, throttling helps maintain optimal performance and reliability of the Microsoft Graph service. For more information, see https://learn.microsoft.com/en-us/graph/throttling. Microsoft enforce throttling limits for Microsoft Graph based on tenant size, including requests-per-minute and requests-per-day. Microsoft does not provide a method for modifying these limits.
Microsoft Power BI REST API
The Microsoft Power BI REST API (Admin API) may experience throttling during usage, as concurrent API access is monitored for any ongoing tasks within a tenant. Discovery tasks are likely to be the most affected by this throttling. We recommend that discovery or statistics collection be run as standalone tasks to minimize potential impacts.
For more information, please reference the following documentation from Microsoft: https://learn.microsoft.com/en-us/rest/api/power-bi/#throttling
- Limitations for reading of workspaces
- Limitations for reading users in workspaces
Handling ODM Throttling
Quest On Demand Migration follows best practices provided by Microsoft when experiencing throttling. These include reducing the number of operations of requests, reducing the frequency of calls and avoiding immediate retries, since all requests accrue against the usage limits for the application.
For requests that an application makes, such as On Demand Migration, including Microsoft Graph, CSOM, or REST calls, Microsoft can return error codes including HTTP status code 429 ("Too many requests") or 503 ("Server Too Busy") which result in the requests to fail. In both cases, a Retry-After header is included in the response indicating how long the calling application should wait before retrying or making a new request.
Upgrading Throttling Policies
Exchange Web Services (EWS) are throttled by Microsoft whenever large quantities of data flows through the EWS platform. The On Demand Migration service throughput can be improved by upgrading the following throttling policy parameter setting to Unlimited:
- EwsMaxBurst - Defines the amount of time that an EWS user can consume an elevated amount of resources before being throttled. This is measured in milliseconds. This value is set separately for each component.
- EwsRechargeRate - Defines the rate at which an EWS user's budget is recharged (budget grows by) during the budget time.
- EwsCutoffBalance - Defines the resource consumption limits for EWS user before that user is completely blocked from performing operations on a specific component.
Tenant administrators can upgrade the throttling policies by making a service request with Microsoft.
To complete a migration project, a lightweight user desktop application called Desktop Update Agent (DUA) must be configured and deployed by administrators and run on users workstations. DUA provides enhanced support, helps ensure the success of cross-tenant migration projects, makes agent delivery easier, and status reporting more informative.
DUA features:
- Ability to manage user’s application reconfigurations activities from a single view within On Demand Migration.
- Support for OneDrive for Business and Microsoft Teams.
- Support for Microsoft 365 application license reset.
- Support for various client authentication mechanisms.
For more information about downloading, administration and use of DUA, see the Quest On Demand Migration Update Agent Guide.
Any full scale migration should be preceded by test and pilot migrations, to confirm that your migration processes and procedures will accommodate the organization requirements.
- A test migration uses real users and real data in a segregated test environment, or dummy users and dummy data in your live production environment.
- A pilot migration uses a small portion of real users and real data in the live production environment.
In either case - a test or pilot migration - the data to be migrated should be a representative sample of the production data, and the test or pilot migration should be run with the Quest applications set for the same configuration and process options that you intend to use for the production migration. it is recommended to select test or pilot users whose usage and data types make them representative of the total user population. Then create and run matching / migration tasks for those accounts, including all range of tasks you are planning to perform. When the tasks are completed, review errors and warnings, if any. See Event Management section for more information.
Quest recommends that you use both test and pilot migrations:
Perform one or more test migrations in a separate test environment, migrating test copies of real users and their real data. The separate test environment ensures that no test process will affect the data or configurations of your production environment. If a test exposes any problems under migration, you can make amendments and then repeat the test by simply dumping the test environment and recreating it from scratch.
When you are confident that your test migrations have sufficiently refined your planned migration, perform a pilot migration for 20 or 30 users to verify if your planned migration is satisfactory for your "real world."
A migration project contains the full set of migration features and provides a summary of all the migration activities in the project dashboard. You can work with a single migration project for small migrations or you can set up multiple migration projects to split larger migration plans into manageable projects.
In this topic:
Creating a new migration project
- Sign in to Quest On Demand.
- From the navigation pane, click Migration to open the Migration projects view.
![](/es-es/technical-documents/image/e2a074fa-a72c-4b7c-ba76-bc47864efccc)
- To use the new project management user interface, turn on the Try the new project wizard toggle.
- Click Create Project.
-or-
If you have already created one or more projects, click Create Project as shown below.
![](/es-es/technical-documents/image/17db0d28-cf3d-4b07-9b1c-5609fabca4f5)
- The New Project wizard starts.
- Step 1: Project Detail
Enter the information in the fields as described below:
- Title - Specify a meaningful name for the project. Maximum number of characters is 128.
- Description - Enter a description about the project. Maximum number of characters is 200.
- Source Tenant - Select a source tenant from the dropdown list.
- Target Tenant - Select a target tenant from the dropdown list.
- Click Save and Continue.
![](/es-es/technical-documents/image/1f8251f2-3fdb-40bb-abd8-6182fe5c46bf)
- Step 2: Assets
Select one or more assets from the set of information assets that you want to migrate. The Account asset is mandatory because all other assets are directly or indirectly linked to active directory accounts in your source and target tenants.
Each asset is treated as an application for migration purposes and automatically assigned a service principal.
- Step 3: Consents
Most Microsoft 365 objects can be migrated when the service principals for each asset have been granted the consent. See Consents and permissions for more information.
To grant consent the service principals:
- Click Grant Consent to grant the consents to the service principal if the tenant consents were not granted when you added the tenants.
-or-
Click Regrant Consent to refresh the consents granted to the service principals. It is recommended that you regrant consent to ensure that the consent to the service principals are refreshed.
- Migration of some Microsoft 365 objects require a user principal with the Global Administrator or other specific roles and you must provide additional authorization. Typically, the tenant administrator credentials are provided. You can provide the credentials for authorization in an Features step.
Select Yes. Proceed to activate the Features step. Select No. Skip to ignore the Features step.
- Click Save and Continue.
![](/es-es/technical-documents/image/e920f067-b6b2-490b-9726-328c8632642b)
- Step 4: Features
![](/es-es/technical-documents/image/e20a1fe2-f342-4891-b4a7-b7f5bf2faf41)
|
NOTE: This step is available if you select Yes. Proceed in the previous step. |
To grant additional authorization with a source and target user principal:
- Enter the email address of the target user accounts.
- Enter the password of the target user accounts.
- Click Save and Continue, or click Skip this page to avoid entering and verifying user principal accounts.
![](/es-es/technical-documents/image/e26515b0-f4ed-4e8d-8bde-253eaedba44c)
- Step 5: Overview
- Verify the information you have provided for each step. Click Edit to return to the step and revise the information as needed.
- Select Open Project to open the project dashboard.
- Click Finish to activate the project.
- Click Open Project to open the project workspace.
Viewing migration projects
- Sign in to Quest On Demand.
- From the navigation pane, click Migration to open the Migration projects view.
- You can view the projects in two formats:
- Tile view
- This view presents each project as a tile. Click
from the view selector in the actions menu to select this view.
- It is the default view and contains links to the migration workspaces from the set of icons in the tile.
- You can sort the tiles by Date Created or Alphabetical from the sort criteria dropdown in the actions menu.
- List View
- This view displays the projects as a list. Click
from the view selector in the actions menu to select this view.
- This view is useful when you have a large number of projects. Click on a column header to sort the list by its column values.
Renaming a migration project
- Sign in to Quest On Demand.
- From the navigation pane, click Migration to open the Migration projects view.
- From the top right-hand corner of the project panel, click the More icon (3 dots). Then click Edit.
- Revise the project name or description as needed.
- Click Save to save the changes and close the dialog.
Deleting a migration project
- Sign in to Quest On Demand.
- From the navigation pane, click Migration to open the Migration projects view.
- From the top right-hand corner of the project panel, click the More icon (3 dots). Then click Delete.
- You can also delete projects from the list view when you select one or more projects and click Delete.
- In the confirmation dialog that opens, click OK to confirm the deletion.
On Demand Migration Workspaces
Click Open Project in the tile view or click a project name in the list view, to open its project workspace. The project workspace displays important information about your project and associated reports. The project workspace contains the following tabs:
In each project, On Demand Migration also creates migration workspaces for each asset class selected for migration. These migration workspaces are logical collections of migration tools for the Office 365 assets and information about the assets in the source and target tenants.
You can go directly to the migration workspace of any asset by clicking the asset icon in the project tile. The icons you see will depend on your role, licenses and the assets selected when the project was created. You can hover over an icon to see the name of the asset type.