EWS recovery needs a migration owner

EWS recovery needs two decisions from a business that depends on an affected application. First, decide whether a temporary recovery has restored the work people need to do. Then keep a named owner responsible for moving that application away from EWS. A working connection is evidence for the first decision. It does not complete the second.

Exchange Web Services, usually shortened to EWS, is a way for applications to communicate with Exchange. Microsoft's current changes concern EWS in Exchange Online, its hosted email service. Dependencies can include older Outlook clients or add-ins and vendor backup applications. Your ordinary email may still work while a separate application fails, so an application error does not establish that all Microsoft 365 email is unavailable.

This article applies if your provider or application supplier has identified an Exchange Online EWS dependency, or is investigating one. Ask them to name the application, the business task it supports and the evidence that EWS retirement caused the failure. Do not assume that every connection error has the same cause.

What Microsoft's October guidance changes

Microsoft's 21 October recovery guidance tells affected organisations to check their tenant's Message Center for a seven-day notice or a notification that EWS has been disabled. The tenant is your organisation's Microsoft cloud environment. Its administrator can inspect those notices and the relevant configuration.

Only a tenant administrator can re-enable EWS under this procedure. Microsoft says its support team cannot do that on the customer's behalf. Use the current official instructions with an authorised administrator rather than copying a generic command or asking a business user to change a setting.

Microsoft says enablement usually takes less than an hour but can rarely take up to four hours. Application allow-list changes take 24 hours. These are different timings, so a supplier should explain which change it made before promising when a test will be meaningful. They are not a guarantee that your whole application will recover within either period.

The updated EWS deprecation guidance also explains the application allow-list requirements for the worldwide multi-tenant cloud. Its EWSAllowedAppIDs setting is different from EWSAllowList. A report that says only "the allow-list is correct" leaves the administrator's actual check unclear. Ask for confirmation against the current guidance and your application's identity, without putting confidential configuration in a general support email.

That article does not establish the same timetable for sovereign cloud environments or on-premises Exchange. Your provider must check which environment you use before applying its recovery process.

Temporary recovery has a limited purpose

Microsoft says re-enabling EWS stops working in April 2027. Its recovery article does not give an exact April day. A vendor application needs an appropriate update, or an organisation's own code needs to change away from EWS. The supplier must establish what the replacement supports and what changes it requires.

Temporary recovery can be a reasonable way to resume an essential task while that work proceeds. It also leaves a dependency with a closing recovery option. Treat it as an approved interim arrangement with an owner, a review date and a migration decision. Planning only to revisit it in April leaves little room for an unavailable supplier update or a failed acceptance test.

An immediate move to a replacement can avoid maintaining the interim arrangement, but it may create a different disruption if the new workflow is untested. An approved manual process may be preferable for a small workload, provided the business can control missed items, duplicates and access. The right choice depends on the work affected and the evidence available, rather than the fact that one setting can be switched back on.

A recovered connection that fails the business check

Consider a fictional distributor whose order-processing application imports requests from an Exchange Online mailbox. Its supplier confirms the EWS dependency, and the administrator finds the relevant disablement notification. The operations manager owns the order workflow. The IT provider owns the authorised tenant change, while the application supplier owns diagnosis and replacement compatibility.

The team agrees a controlled acceptance check using non-sensitive test requests. One contains an attachment required to process the order. Another represents an item that arrived during the interruption. The expected result is that each appears once in the processing queue, with the information staff need to continue. They also agree how to stop testing and recover safely if it creates an incorrect item. These are fictional acceptance requirements, not a claim about a particular application.

After the administrator follows Microsoft's current recovery procedure and allows for the relevant change timing, the application connects. The supplier proposes closing the incident. The operations manager checks the agreed results first. The ordinary request appears, but the attachment-bearing request is absent from the processing queue.

She keeps the incident open. A successful connection has not restored the complete task. The team preserves the failed result for diagnosis and uses its approved manual queue for urgent requests. Staff record which items they process manually so that a later retry does not create duplicate work. They do not repeatedly change tenant settings merely because the first business check failed.

In this fictional example, the supplier subsequently identifies and corrects an application processing problem. The team repeats the checks and reconciles the requests received during the interruption against the application queue and manual record. Each required request is accounted for, its attachment is available where needed, and no request will be processed twice. The operations manager accepts temporary operational recovery on that evidence.

If the missing item remained unexplained, the decision would stay open. The manager would review whether the manual queue could meet the workload and escalate any limit before promising normal service. Technical staff would continue diagnosis rather than treating the retirement notice as proof that every remaining fault had the same cause.

Keep migration open after recovery

The distributor's incident can now close as temporarily recovered. Its IT lead keeps a separate migration action open, with the application supplier responsible for providing a supported route away from EWS. The lead asks for the proposed version or design, required permissions, dependencies, delivery dates and evidence that the essential order workflow is covered. A statement that an update is "on the roadmap" is not an accepted delivery commitment.

For this fictional decision, the supplier provides a candidate update and an agreed test plan. The business chooses a staged migration because the order workflow has attachment and backlog requirements that a login test would miss. It accepts the extra work of maintaining the interim process while checking the replacement. The IT lead sets an internal deadline before April, with time for correction and a named escalation point if the supplier misses its commitment.

The replacement must pass the workflow checks, including interruption and retry handling, in an appropriate test environment. The administrator also reviews its access requirements. Passing a functional test does not justify granting unexplained permissions. A failed check holds the migration open while the supplier corrects the defect or the business selects another supported route.

Following successful tests and an approved production change, the operations manager verifies the actual order flow and reconciles outstanding items. Technical staff confirm that this application no longer relies on EWS. The IT lead can then accept its migration and arrange removal of temporary allowances that are no longer needed. Other applications may still depend on them, so their removal requires a separate dependency check. Closing this application's action does not certify the whole organisation's migration.

This division of responsibility also makes supplier progress reviewable. The business accepts the outcome it needs; the supplier demonstrates compatibility; the administrator controls tenant changes. Your IT supplier management arrangements should make those responsibilities explicit rather than leaving them between support contracts.

Agree the next decision with your provider

Start with the affected application and the task that failed. Ask the provider to show the retirement evidence, explain the proposed recovery change and agree what business result will justify accepting it. Before closing temporary recovery, name the migration owner and the next dated supplier decision. Keep the supported replacement, test evidence and remaining dependencies visible in your IT plan.

IT management support can help coordinate supplier commitments, agree operational acceptance and prioritise migration work alongside other business needs. Tenant configuration and application engineering remain with the appropriately authorised technical people under the agreed scope.

Discuss ownership of your EWS recovery and migration. Bring the application name, the affected business task and a redacted summary of the supplier's proposed route. Do not include credentials or confidential tenant exports. The starting decision is who will own the work that remains after the connection comes back.