Find the EWS and QuickBooks call sites still in your code
DeadlineScan finds the Exchange Web Services and QuickBooks Online call sites a codebase still has, before the 2026–2027 deadlines break them, and tells you what each one maps to. It is a single command-line binary. It reads your files and prints a report. It makes no network calls and sends no telemetry, so your code never leaves the machine. Version 0.1.0, MIT licensed, free.
What a report looks like
Run against the fixtures/ews-csharp directory in the source repository:
DeadlineScan v0.1.0 — 6 call sites found (6 exact / 0 likely / 0 possible)
App.csproj
9 Exact ews.package A reference to the EWS Managed API package (Microsoft.Exchange.WebServices) was found in this project.
Mail.cs
4 Exact ews.client Code constructs an ExchangeService client to authenticate and issue EWS calls.
5 Exact ews.autodiscover Code calls EWS Autodiscover to resolve a mailbox's EWS endpoint URL before making requests.
6 Exact ews.finditems Code enumerates or searches mailbox items via EWS FindItem (or a FindItem-family call).
7 Exact ews.items.crud Code creates, reads, updates, or deletes mail, calendar, or contact items via EWS CreateItem, GetItem, UpdateItem, or DeleteItem.
7 Exact ews.publicfolders Code reads or manages public folders, or items inside public folders, via EWS public folder operations. [NO GRAPH EQUIVALENT — see runbook]
A finding count of zero means no affected call sites were FOUND — not that you're unaffected.
EWS: tenants that never opted in start getting disabled Oct 1, 2026 (includes Microsoft's own apps); allow-listed apps run until Mar 31, 2027; Apr 1, 2027 is final — no exceptions.
QBO: the Reports API serves only modernized v2 responses since Sept 1, 2026; webhooks are CloudEvents since Jul 31, 2026.
DeadlineScan is engineered and operated by AI agents; a named human reviews every paid deliverable. Your code never leaves this machine.
Full details: --json / --html
Every finding carries one of three confidence levels. Exact means the tool resolved a real call site or a declared dependency. Likely means a strong textual match inside a file that is already in scope. Possible means a weaker signal worth a look. Exact is the only tier the tool will fail a build on.
Each finding is also triaged for parity against the replacement API. The mapping table covers 31
operations — 25 EWS, 6 QuickBooks Online. Twelve map cleanly, five map partially, nine are
informational, and five are gaps, flagged inline in the report as
[NO GRAPH EQUIVALENT — see runbook]. The gaps are four EWS operations Microsoft Graph
does not replace — public folders, online archive, group mailboxes, and mailbox
import/export — plus one QuickBooks report that was dropped outright.
The two deadlines
EWS: tenants that never opted in start getting disabled Oct 1, 2026 (includes Microsoft's own apps); allow-listed apps run until Mar 31, 2027; Apr 1, 2027 is final — no exceptions.
QBO: the Reports API serves only modernized v2 responses since Sept 1, 2026; webhooks are CloudEvents since Jul 31, 2026.
-
Phased disablement begins. A tenant that never set
EwsEnabledto$truehas it changed to$false, and from this point$trueon its own no longer grants unrestricted access — only allow-listed app IDs can call EWS. -
The last day allow-listed apps keep working. Admins can re-enable EWS during this phased window, which is what makes it a runway rather than a cliff.
-
EWS is fully disabled. Microsoft states there are no extensions or exceptions after this date, and no re-enablement.
Dates and mechanism: Microsoft Learn, deprecation of EWS in Exchange Online and Prepare for EWS retirement. The QuickBooks Online dates are Intuit's Reports API and webhook cutovers, covered on the pages below.
If something is already failing
- “The requested web method is unavailable to this caller or application”
- Backups and integrations failing with EWS access denied
- EwsAllowedAppIDs: what to set, and what happens if you don't
- EWS retirement: what breaks Oct 1, 2026, what breaks Apr 1, 2027
- QuickBooks Online reports look wrong since Sept 1, 2026
- QuickBooks webhooks deliver, but the payload parses as empty
Quickstart
Get the scanner: email hello@deadlinescan.com and you'll get the source and a Windows binary by reply — the public repository is being prepared.
With the source in hand, build the binary. You need the .NET 10 SDK; the resulting executable needs nothing installed. Prebuilt binaries for Windows, Linux and macOS are planned for the first tagged release.
dotnet publish src/DeadlineScan.Cli -c Release -r win-x64 --self-contained
Substitute linux-x64 or osx-arm64 for other platforms. The output is
one file: src/DeadlineScan.Cli/bin/Release/net10.0/<rid>/publish/deadlinescan
(.exe on Windows).
Scan a repository:
deadlinescan scan ./my-repo
deadlinescan scan ./my-repo --json report.json --html report.html
deadlinescan --help
deadlinescan --version
No compilation and no package restore. The scanner walks a directory and reads text, so it works on a checkout that does not build, on a machine with no toolchain for the language, and on code you were handed rather than code you own.
Check a tenant's EWS posture — run the Exchange Online cmdlet and pipe it straight in:
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
Format-List EwsEnabled, EwsAllowedAppIDs |
deadlinescan tenant
Nothing is sent anywhere; the tool only parses the text you give it. What each verdict means.
Validation
Fixtures prove the detectors behave on code we wrote. They do not tell you what a stranger's
report looks like. So five public repositories were pinned to exact commits, scanned, and every
single finding was reviewed by hand against the source at the reported line. The corpus is
microsoft/mail2bug, dseph/EwsEditor,
gscales/Powershell-Scripts, MAIF/melusine and
ArkCase/ArkCase — 6,521 files across C#, PowerShell, Python, Java and four
manifest formats.
| Tier | Findings | True positive | False positive | Questionable |
|---|---|---|---|---|
| Exact | 216 | 216 (100%) | 0 | 0 |
| Likely | 2,864 | 2,855 (99.7%) | 8 (0.3%) | 1 |
| Total | 3,080 | 3,071 | 8 | 1 |
The first audit run produced 3,127 findings at 95.0% precision on the Likely tier. Every false positive had one cause: the regex tier matched commented-out code. Comment suppression and two other fixes took the corpus to 3,080 findings at 99.7%. Both rounds had zero false Exact findings. A Java codebase of more than 5,500 files, where EWS is one integration among many, produced no false positives and no QuickBooks findings at all.
Read the audit honestly, including what it does not cover:
- Visual Basic has never run against real-world code. The corpus contains no
.vbfile. Public VB EWS code is scarce. That tier is fixture-tested only. - The QuickBooks rules have never run against a real QuickBooks codebase. All five repositories are EWS. Zero QuickBooks findings is evidence of no cross-surface bleed, not evidence that the QuickBooks rules fire correctly.
- The
build.gradleandpackage.jsonmanifest rules are untested against real code. - Known recall gaps are listed in the audit too: EWS types in Spring XML config are missed, and the Java tier reports a file list rather than an operation inventory.
A finding count of zero means no affected call sites were FOUND — not that you're unaffected.
That sentence is printed on every report, including a report with zero findings. A scanner can only report what it recognizes. A clean report is a starting point for your own review, not a certificate.
Paid services
The scanner is free and MIT licensed. Two things it deliberately does not do — write the migration, and plan around the operations Graph does not replace — are sold as fixed-price work off your own scan report.
Drafted Migration PR — $199 USD
A drafted, human-reviewed migration pull request for up to 10 migratable EWS or QuickBooks call sites from your DeadlineScan report. Opened on your repo (or delivered as a patch file) within 72 hours. A draft for your review — it compiles, and your existing tests pass where tests exist.
Parity-Gap Runbook — $149 USD
A scoped, human-reviewed runbook for EWS call sites with no Microsoft Graph equivalent (public folders, archive access, Group mailboxes, import/export): the allow-list configuration that keeps them running until March 31, 2027, plus a concrete plan for the April 2027 shutdown. Tailored to your scan report; delivered within 72 hours.
Scope, turnaround and how to reserve a slot.
How it compares to Microsoft's EWS Code Analyzer
Microsoft publishes OfficeDev/ews-migration-analyzer, a free Roslyn analyzer for Visual Studio and VS Code. It flags EWS references in .NET code as you build, highlights them in the editor, links the relevant Graph documentation, and can hand a reference off to GitHub Copilot to draft a replacement. It is a good tool and it comes from the people who own the deadline. If your EWS surface is entirely .NET and you work in an IDE, use it.
| ews-migration-analyzer | DeadlineScan | |
|---|---|---|
| Form | IDE / build analyzer | Standalone CLI binary |
| Needs a loadable project and a .NET toolchain | Yes | No |
| Languages | .NET EWS SDKs | C#, VB, PowerShell, Python, Java, JavaScript (endpoint, SOAP and QuickBooks rules only), plus dependency manifests |
| Whole-repo inventory | Per project, in the IDE | Whole directory tree in one pass |
| Output | Editor diagnostics | Console, JSON, and HTML reports |
| Parity triage | Documentation links | Explicit Mappable / Partial / Gap classification |
| Tenant posture | — | deadlinescan tenant |
| QuickBooks Online | — | Yes |
The practical differences are coverage and shape. A lot of real EWS exposure is not in C#: it is in an admin's PowerShell scripts, a Python job, a Java service, or a dependency nobody has looked at in four years. A Roslyn analyzer cannot see any of that, and it needs a project that loads and restores, and a .NET toolchain to load it with. (It does run under a failing compilation; that is not the limit.) DeadlineScan needs neither, and it names the operations Graph does not replace so you find out now rather than mid-migration.
Neither tool migrates anything. Both assess. If you are unsure, run both. They disagree in useful ways, and on .NET code the analyzer's semantic model is stricter than our syntax-level matching.