Microsoft 365 integrations 2026: 3 failure modes and what Graph work costs

Summary. Most Microsoft 365 integrations do not fail because the code was wrong. They fail because the platform moved and nobody owned the rebuild. Microsoft applies a global ceiling of 130,000 requests per 10 seconds per application across all tenants on Microsoft Graph, and much tighter service ceilings underneath it: 5,000 requests per 10 seconds per app for Excel, 1,500 per 10 seconds per app per tenant, 10,000 presence requests per 30 seconds per application per tenant, and 100 Exchange message trace requests per 5 minutes per tenant. Meanwhile Exchange Web Services stops accepting requests from 1 October 2026 and is removed permanently on 1 April 2027, and Microsoft raised Office 365 E3 by 13% from $23.00 to $26.00 per user per month on 1 July 2026. Three failure modes explain almost every broken integration we are asked to rescue: no throttling headroom, no subscription lifecycle handling, and permissions copied straight from the legacy model. This is what the work contains, what drives its cost, and how to scope it with a partner.

Why Microsoft 365 integrations keep getting rebuilt

The Microsoft 365 platform retires interfaces on a published cadence, and the retirements land on integrations rather than on end users. That is the structural reason a mail-sync service written in 2019 needs money spent on it in 2026 even though nothing about the business requirement changed.

The pattern generalises. The point is not that Microsoft is unusually aggressive; the Bing Webmaster Tools SOAP and POX API retirement followed the same shape, and so did the Content API for Shopping. What separates teams that spend two weeks on a migration from teams that spend two quarters is whether the original integration was built with the platform's constraints in the design or discovered them in production.

If the EWS deadline is what brought you here, the operational sequence is covered separately in our EWS allow list and Graph migration runbook. This article is about what the engineering work contains and what it costs to buy.

Failure mode 1: no throttling headroom

Microsoft Graph is a single endpoint over many services, and each service enforces its own limits. The global limit is generous. The service limits are not, and they are the ones that break batch jobs.

Two design consequences follow. The first is that a nightly job which iterates mailboxes or workbooks in a tight loop will work in a demo tenant of 20 users and fail in a tenant of 20,000, because the limits are per app and per tenant rather than per user. The second is that the failure is silent from the business side: a throttled job usually completes with partial data rather than erroring loudly, which is how reconciliation reports quietly go wrong for a quarter before anyone notices.

Microsoft ships an early-warning signal that few integrations read. The x-ms-throttle-limit-percentage response header is returned once an application has consumed more than 0.8 of its limit, on a scale that runs from 0.8 to 1.8. Microsoft's documentation is explicit about what the values mean: 0.8 indicates 80% of the granted limit consumed, 1.0 is the point where throttling starts, 1.2 indicates 20% of incoming requests are being throttled, and 1.8 indicates 80% are. An integration that emits that header value as a metric gives you weeks of warning before a customer calls. An integration that ignores it gives you an incident.

One more trap worth naming: Microsoft's identity and access policy operations and its identity protection and conditional access resources do not return a Retry-After header on 429 responses. Retry logic that waits for the server to tell it how long to back off will spin.

Failure mode 2: subscriptions treated as fire and forget

Change notifications are how a modern Microsoft 365 integration avoids polling, and they are the part most often built to the happy path. Microsoft Graph sends three kinds of lifecycle notification to a separate lifecycleNotificationUrl, and each one requires the application to do something.

reauthorizationRequired fires when the access token is about to expire, when the subscription is about to expire, or when an administrator has revoked the app's permission to read a resource. Microsoft's own documentation says change notification delivery eventually pauses until the app responds, and that any resource changes occurring during the pause are lost and must be refetched with a delta query.

subscriptionRemoved fires when Microsoft Graph has removed the subscription outright. There is no set cadence for these events; Microsoft's phrasing is that they might occur frequently for some resources and almost never for others. The app has to create a new subscription and then resync.

missed fires when change notifications were not delivered, for example because of throttling. The only correct response is a full data resync of the resource.

Three implementation details decide whether this works. The app must respond to each lifecycle notification with 202 - Accepted and validate its authenticity. The lifecycleNotificationUrl cannot be added to an existing subscription by updating it; you have to delete the subscription and create a new one with the property set, which means retrofitting lifecycle handling onto a running integration is a migration, not a patch. And Microsoft warns against issuing a POST /subscriptions/{id}/reauthorize and a PATCH /subscriptions/{id} for the same subscription inside a 10-minute window, because concurrent or rapid-succession requests can leave the subscription state inconsistent. The supported way to reauthorize and renew at once is a single PATCH with an updated expirationDateTime.

            PATCH https://graph.microsoft.com/v1.0/subscriptions/{id}
Content-Type: application/json

{
  "expirationDateTime": "2026-08-09T11:00:00.0000000Z"
}
          

Maximum subscription lifetimes vary by resource type, so a renewal scheduler that assumes one interval across mail, calendar and chat resources will drop notifications on whichever resource has the shortest window. Read the subscription resource reference for the resource you are subscribing to before you pick the interval.

Failure mode 3: permissions copied from the legacy model

The third failure mode is the one auditors find. Microsoft's own rationale for moving off EWS is that Graph applies OAuth with granular scoping to limit data access inside a mailbox, against what it calls the all or none access model in EWS. A migration that ports the calls but keeps the old permission shape moves the code and leaves the risk.

In practice that means an application granted tenant-wide mailbox access because EWS offered nothing narrower, still holding tenant-wide mailbox access on Graph in 2027 because nobody revisited the consent during the port. The correct sequence is to establish which mailboxes the integration actually touches during the discovery phase, then request the narrowest Graph permission that covers them, then scope application access to that mailbox set rather than the whole tenant.

This is also where a migration pays for itself in something other than continuity. Mailbox contents are personal data under the Digital Personal Data Protection Act 2023 in India, and a broad standing grant across every mailbox in a tenant is difficult to defend in a data protection review. We design application permissions aligned with DPDP Act requirements rather than reproducing the legacy access model, and the narrowing is cheapest to do while the code is already open.

What the work actually contains

A Microsoft 365 and Graph integration engagement is mostly not writing Graph calls. Sized honestly, the phases look like this.

Discovery produces the register: every application calling the platform, its Microsoft Entra application ID, the operations it uses, its call volume, its last activity date, and a named owner inside the business. For Exchange workloads the EWS usage report in the Microsoft 365 admin center supplies Application ID, SOAP Action, Call Volume and Last Activity date across 7, 30 or 90 days, with data aggregated weekly rather than daily.

Mapping turns the operation list into a work estimate. Microsoft publishes operation-level mappings from EWS to Graph, and the rows that map cleanly, such as FindItem to list messages or SyncFolderItems to the messages delta query, are the ones a developer ports quickly. Applications using EWS pull notifications move to the delta query rather than to subscriptions, because Graph requires a subscription only for push.

Build is the Graph implementation: authentication through Microsoft Entra, least-privilege scopes, delta queries for synchronisation, subscriptions with lifecycle handling for push, backoff that reads the throttle headers, and structured logging that records the header percentage as a metric.

Hardening and handover is the phase buyers cut and later regret. It covers load testing against realistic tenant sizes rather than a demo tenant, an operational runbook for the three lifecycle events, alerting on throttle percentage and on subscription age, and documentation of the permission grants with a review date.

How to cost it: the five drivers

Ask any partner to price these five drivers separately, because they move independently and the third one is where estimates go wrong.

The single largest variance is the third row. An application that only reads and sends mail is a port. An application built on EWS impersonation or on extended properties is a redesign, and Microsoft's published roadmap still lists mailbox import and export as preview, with public folder and Microsoft 365 Groups import and export outstanding. Backup, archiving and mailbox migration tooling sits almost entirely in that column, which is why vendor upgrade timelines in that category slip more than others.

The honest advice on the fourth row: load test against a tenant that resembles production before you agree a cutover date, not after. The per-app-per-tenant limits are the ones that surprise teams, and discovering a 1,500-requests-per-10-seconds ceiling three days before go-live turns a port into an architecture change.

India-specific considerations

Indian enterprises and global capability centres carry a specific version of the ownership problem. A large share of Microsoft 365 integrations across Indian delivery estates were built by vendor teams under fixed-scope contracts that closed years ago. The application still runs, the Entra application ID is still consented, and the contractual owner is gone. Vendor conversations need to start at the beginning of the engagement rather than at the point of cutover.

The licensing arithmetic also lands differently here. Frontline SKUs are heavily deployed across Indian retail, logistics and manufacturing, and those repriced hardest on 1 July 2026: Microsoft 365 F1 rose 33% from $2.25 to $3.00 per user per month and F3 rose 25% from $8.00 to $10.00, against 8% for Microsoft 365 E3 at $39.00 and 5% for E5 at $60.00. Any remediation plan that assumes moving a frontline population to a richer SKU should be priced at the new rates before it goes to a finance committee.

Data residency and consent sit on top. Integration work that reads mailboxes, calendars or files touches personal data under the DPDP Act 2023, and the review a data protection officer runs is about scope of access rather than about which API you used. Narrow scopes are easier to explain than broad ones.

How we run these engagements

eCorpIT is a Gurugram technology consultancy founded in 2021, working with clients in India and abroad. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified, and we are a Microsoft partner alongside AWS, Google, Shopify and Kaspersky.

Our senior engineering teams run Microsoft 365 and Graph work in the order above: discovery register first with a named owner per row, then the operation mapping and estimate, then the build with least-privilege scopes and lifecycle handling, then hardening with load tests against realistic tenant sizes. Engagements are structured either as a fixed-scope migration where the register is already complete, or as a discovery sprint followed by a scoped build where it is not. We do not quote a build before the register exists, because the register is what determines whether a job is two weeks or two quarters.

The same engineering discipline runs through our wider API integration modernisation service and our release engineering and CI/CD platform work, and the platform-level view of why interfaces move on published dates sits in our web platform and API developer guide.

FAQ

How eCorpIT can help

eCorpIT builds and modernises Microsoft 365 and Microsoft Graph integrations for enterprises in India and abroad, from the discovery register through to a hardened, monitored production service. Our senior engineering teams work in the sequence that keeps estimates honest: inventory and ownership first, operation mapping and estimate second, build and hardening last. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified, and we design application permissions to the narrowest scope a workload needs rather than reproducing a legacy access model. If you have an EWS deadline in October or an integration that keeps breaking after platform updates, talk to our team.

References

1. Microsoft Graph service-specific throttling limits. Microsoft Learn, global and per-service request ceilings.

1. Microsoft Graph throttling guidance. Microsoft Learn, backoff and retry behaviour.

1. Reduce missing subscriptions and change notifications. Microsoft Learn, the three lifecycle notification types.

1. subscription resource type. Microsoft Learn, per-resource subscription expiration limits.

1. Migrate Exchange Web Services (EWS) apps to Microsoft Graph. Microsoft Learn, OAuth scoping and REST rationale.

1. Exchange Web Services (EWS) to Microsoft Graph API mappings. Microsoft Learn, operation-level mapping tables.

1. Deprecation of Exchange Web Services in Exchange Online. Microsoft Learn, timeline and Graph parity roadmap.

1. MC1227454: Exchange Web Services (EWS) retirement update. Microsoft 365 Message Center archive, 5 February 2026.

1. Retirement of Exchange Web Services in Exchange Online. Microsoft 365 Developer Blog, the 2023 announcement.

1. Control access to EWS in Exchange. Microsoft Learn, EWSEnabled and EwsAllowedAppIDs.

1. Exchange Web Services (EWS) usage report. Microsoft Learn, discovery report columns and filters.

1. Microsoft 365 Pricing and Packaging Updates. Microsoft Licensing Resources, commercial pricing effective 1 July 2026.

Last updated: 6 August 2026.