Skip to content

Service prioritization for a migration platform: is this the right route, and how does it work? #11067

Open

Description

Hi,

We run a migration platform that moves document archives of accounting firms in the Netherlands into SharePoint Online. It writes through Microsoft Graph, app-only, with one multitenant app registration that each customer consents to. Our customers are small tenants, usually under 1,000 licenses.

We consistently run into the per-app limits: 1,250 resource units per minute and 1,200,000 per 24 hours. One document costs us about 5 resource units (a GET, an upload and a fields PATCH), so we top out at roughly 250 documents per minute and 240,000 per day per tenant. A firm with a million documents therefore needs more than four days, while customers want to move over one weekend. We honor Retry-After, decorate our traffic with a NONISV User-Agent, and run in the evenings and weekends.

As far as we can tell, service prioritization in SharePoint is the only realistic and supported option for us: a second app registration is explicitly discouraged, and the migration guide says throttling cannot be lifted through support. Is that right, or is there another route we should look at?

If service prioritization is the right route, could you help us with these questions:

  1. Can a customer register a multitenant app (AppId homed in our tenant, consented in theirs) with Add-SPOServicePrioritizationAppRegistration?
  2. Is the Microsoft Graph metered API association (Microsoft.GraphServices/accounts) also required? If so, in the customer's Azure subscription or in ours?
  3. Does the QuotaMultiplier raise both the 1-minute and the 24-hour per-app limits? Does it also raise the tenant-level limit of 18,750 resource units per 5 minutes?
  4. "Billed for any requests above the regular application limits": measured per minute or per 24 hours?
  5. Which of these calls are Standard and which are Heavy: GET driveItem, PUT .../content (small upload), createUploadSession, the chunk PUTs to the uploadUrl, PATCH listItem/fields, GET .../content (download), delta with a token?
  6. Is it available and billed for tenants in the EU? The Azure retail prices API only shows the "SharePoint APIs Extended Usage" meters for a US Gov location.
  7. How soon after registration does it take effect, and how can we verify that it is active?

Docs referenced:

Thank you.

Activity

  1. m365-agent-toolkit-assistant commented on Oct 19, 2026

    @m365-agent-toolkit-assistant

    👋 Hi Tijn Kahmann (@Tijn1946),

    Thank you for reporting this issue. Here is an AI-generated initial response:

    Classification: By design — the reported per-app throttling limits are documented; this does not indicate a defect.

    • Service prioritization can raise application resource limits by 2–10× when capacity is available. It is not a guaranteed weekend throughput rate. The published guidance does not say that it raises the separate tenant-wide limit or specify which of the 1-minute and 24-hour thresholds its multiplier changes.
    • It is not the only route: Microsoft recommends evaluating the SharePoint Migration API for bulk imports before using Graph calls per document. Also, a migration vendor should use the documented ISV, rather than NONISV, User-Agent format.
    • The setup guidance leaves material questions unanswered for your arrangement: customer registration of a vendor-owned multitenant App ID, how its Graph metered-API association fits the customer’s billing policy, the billing threshold’s time window, endpoint-by-endpoint Standard/Heavy classification, EU pricing, and activation time. Do not infer answers from the retail-prices result.

    What to do now:

    1. Assess whether CreateMigrationJob supports your archive and metadata requirements.
    2. Before budgeting a prioritized migration, ask Microsoft to confirm those setup and metering details. Check the customer’s registration with Get-SPOServicePrioritizationAppRegistrations, then validate throughput and charges in a controlled run.

    Useful links:


    Note: AI-generated guidance may be incomplete or incorrect. Please verify suggestions before applying them.

  2. Tijn1946 commented on Oct 19, 2026

    @Tijn1946
    Author

    Thanks for the pointers. Two follow-ups for someone on the SharePoint team:

    1. The ISV migration guide says "Please register all your migration app IDs with Microsoft to ensure that you receive adequate throughput for your migration jobs." How and where do we register our app ID? We could not find a form or contact for it.
    2. The service prioritization questions above (multitenant AppId registration, which limits the multiplier raises, billing window, Standard/Heavy per call, EU availability) are still open. We would appreciate an answer from the product team before we offer this to customers.

    Thank you.

  3. Ashlesha-MSFT commented on Oct 21, 2026

    @Ashlesha-MSFT
    Contributor

    Hi Tijn,

    Thanks for providing the detailed scenario and questions.

    The documentation confirms that SharePoint service prioritization supports a quota multiplier of 2×–10× and bills requests above regular application limits. However, the documentation does not explicitly clarify the multitenant app registration scenario, quota multiplier scope, billing details, API classifications, EU availability, or activation time.

    I will tag the relevant SharePoint engineering/product team to help clarify these points and confirm the supported configuration.

    References:

    SharePoint service prioritization
    SharePoint throttling guidance
    Migration performance guidance

  4. Tijn1946 commented on Oct 21, 2026

    @Tijn1946
    Author

    Thanks Ashlesha. Could you also pass question 1 to the team: how and where do we register our migration app ID, as the ISV migration guide asks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions