Small and Owned
EN ES
Automate

October EWS Cutoff: Solo Operator's Email and Calendar Checklist

A solo operator can keep email and calendar automations running by inventorying dependencies now and moving them to a newer API with event-based sync and stricter request limits.

Illustration: October EWS Cutoff: Solo Operator's Email and Calendar Checklist

The quiet failure mode for a solo operator is not a loud outage. It is an invoice automation that stops after a cloud change, a calendar sync that drifts, or a receipt parser that no longer sees the right folder. The fix is boring: count the dependencies, move the ones that matter, and leave a narrow exception for the rest. The Exchange Online EWS shutdown, in Microsoft's cloud email service, is staged, beginning October 1, 2026, and ending with permanent retirement on April 1, 2027. That gives you time to do it calmly.

For a one-person business, the margin comes from not spending hours on fragile automation. If an automation touches email, calendar, invoices, or receipts, it deserves a place in a small inventory. You do not need a project team. You need a dated checklist, a few admin tools, and a rule that every future change gets recorded.

The deadline is a maintenance window, not a panic

Basic authentication for Exchange Online EWS, POP, IMAP, and ActiveSync stopped on October 1, 2022. That means the old password-based shortcuts are already gone in the cloud. Microsoft Graph requires OAuth 2.0 through Microsoft Entra ID, Microsoft's identity service. If your automation still leans on a stored password, the migration is not optional. It is the only supported path.

The inventory comes before the code changes

Keep one list. Each item should be testable in a minute: you can open the tool, run the check, and mark it done. The list below is the one to keep.

  1. List every automation that touches email, calendar, invoices, or receipts, and note the trigger, owner, and endpoint.
  2. Run the EWS Analyzer against your tenant and save the output.
  3. Open the EWS Usage Reports and identify the top app IDs and call patterns.
  4. Mark each dependency as migrate or allowlist, and write the reason in one sentence.
  5. Create or review a Microsoft Entra ID app registration for the Graph work.
  6. Store the client ID and secret in a secret manager, not in a script.
  7. Set the automation queue to no more than 4 concurrent Graph calls per app ID and mailbox.
  8. Replace repeated polling with event-based sync where the flow allows it.
  9. Run a test invoice, receipt, or calendar event and confirm the result appears.
  10. Record the August 2026 allowlist deadline in your admin calendar.

Microsoft provides the analyzer and usage reports for finding EWS dependencies. The first three items exist because you cannot migrate what you cannot see. The analyzer and reports are the cheap version of a code audit. The next items exist because Graph authentication is different from the old EWS habits. The concurrency item exists because Graph is stricter than the old service. The test item exists because a solo operator cannot afford a silent failure.

Graph works better with smaller, steadier requests

Graph applies Outlook service limits of 10,000 API calls in 10 minutes, 4 concurrent requests, and 150 MB of uploads in 5 minutes, per app ID and mailbox. By comparison, EWS in Exchange Online allowed 27 concurrent connections, with throttling policies configurable by tenant admins. The practical difference is that your automation should stop trying to fan out. Batch the work. Queue the calls. Let one mailbox finish before the next one starts.

For a solo operator, the durable trick is to make the automation smaller, not faster. If a receipt parser needs to read a folder, do it once per event instead of every minute. If an invoice flow needs to create a calendar block, send one request with the fields it needs. If a tool polls for changes, move it to an event-based pattern. The goal is fewer calls, not more clever code.

OAuth 2.0 also changes how you think about access. The app registration is the identity. The token is the permission. The mailbox is the boundary. If you can explain those three things to a future self, the automation is easier to trust. If you cannot, the code is doing more than it should.

The allowlist is a last resort

If a dependency is too risky to migrate before the cutoff, the exception path is narrow. If a solo operator still needs EWS after October 2026, the tenant must have an AppID AllowList and EWSEnabled=True set before the end of August 2026. That is a dated permission, not a free pass, to keep one old door open while you finish the move.

Use the allowlist only for a named app ID, a named mailbox, and a named deadline. Do not allowlist a category. Do not allowlist because a vendor has not replied. Do not allowlist because the code is old. The allowlist is a temporary exception, not a permanent design.

Put the checklist where you keep the app ID and the secret. When a new automation touches email or calendar, add it to the list before it goes live. That keeps the next change small.

Advertisement