EWS Retirement Checklist

What is the EWS retirement timeline?

Microsoft's Exchange Online EWS retirement starts October 1, 2026 and reaches full disablement on April 1, 2027. The deadline applies to Exchange Online, while on-premises Exchange Server deployments follow a different support path, so inventory work should separate cloud mailboxes from local servers.

Microsoft's official EWS deprecation notice names Microsoft Graph as the strategic replacement. That works for many workloads, but teams still need to map each EWS script to Graph support, a CLI workflow, or a provider abstraction before the cutover window.

How do you inventory risky EWS scripts?

Start by finding code that imports EWS libraries, hardcodes autodiscover URLs, or calls mailbox methods directly. A 30-minute repository scan usually finds the highest-risk scripts: service jobs, report senders, mailbox processors, room booking scripts, and legacy PowerShell wrappers.

Run this scan from the repository root and save the output as your migration list. The patterns cover common .NET, PowerShell, and Java EWS signatures, and the exact file paths help assign each workflow to email, calendar, contacts, or archive review.

rg -n "ExchangeService|EWS|EwsUrl|FindItems|SendAndSaveCopy|AutodiscoverUrl|GetFolder|UpdateItem" .

Tag each result with one of 4 workflow types: email read, email send, calendar, or archive. That classification keeps migration work small. Email reads can often move to nylas email list or nylas email search; email sends can often move to nylas email send; calendar checks usually start with nylas calendar events list.

Which migration path is safest?

The safest migration path depends on how much provider-specific behavior the script uses. Simple inbox reads and sends can move to a CLI command in 1 day, calendar workflows may need Graph parity checks, and archive or public-folder workloads need a focused gap review.

For details on Graph API gaps, auth changes, and feature mapping, use the deeper EWS to Microsoft Graph migration guide after the inventory step.

If you choose Graph directly, start with Microsoft's Microsoft Graph overview and Graph throttling guidance. These documents help separate API shape work from rate-limit and retry work before the 2027 disablement date.

What should the migration phases be?

Run the EWS migration in 4 phases: inventory, smoke test, rewrite, and parallel run. Inventory finds every EWS dependency. Smoke tests prove the replacement grant can read mail and calendar data. Rewrite changes the lowest-risk scripts first. Parallel run compares old and new output for at least 7 days before the EWS path is disabled.

The low-risk first batch is usually 5 scripts or fewer: daily report sender, alert email sender, recent-message report, calendar availability check, and one admin notification. Avoid starting with archive export, public folders, or delegate mailbox logic because those workflows carry more Exchange-specific assumptions.

How do you test Exchange access from the terminal?

Test Exchange mail and calendar access before rewriting any application code. The goal is a 2-command smoke test: read 10 recent messages and list the next 14 days of events. Passing both checks proves authentication, mailbox visibility, and calendar scope are working.

These commands use the same CLI account configuration your migrated scripts will use later. If either command fails, fix auth and grant selection before debating Graph schemas or EWS replacement details.

nylas email list --limit 10 --json
nylas calendar events list --days 14 --json

If the smoke test runs in CI or a scheduled job, configure the API key with nylas auth config first and check the active grant with nylas auth status. That keeps migration failures in the terminal output instead of in an application stack trace.

Where do Agent Accounts fit in an EWS migration?

Agent Accounts fit when the replacement workflow should own its sender identity. For example, a legacy EWS job that sent reminders from a shared automation mailbox can move to a provider=nylas Agent Account instead of a human Exchange mailbox. That gives the job its own address, webhook stream, policy controls, and calendar.

Use connected Exchange grants when the workflow must read or write a user's real Exchange mailbox. Use nylas agent account create when the automation should have an app-owned identity. The split prevents migration work from blindly recreating old shared-mailbox habits on a new API.

How do you prove the replacement is safe?

Prove the replacement by running old and new paths side by side for 7 days on read-only or low-risk workflows. Compare message counts, event counts, recipients, and error rates. A migration that returns the same 10 recent messages and the same 14 days of events is safer to ship than one validated only by a successful login.

For send workflows, start with a distribution list controlled by the migration team. The first 5 messages should include the script name, environment, and migration ticket in the subject or metadata so failures can be traced quickly. Do not cut over external customer sends until the internal run has a clean audit trail and a rollback command.

Keep both command and provider evidence. Graph parity might prove the Microsoft API shape, while nylas email send, nylas email list, and nylas calendar events list prove the CLI path the migrated job will actually run.

What rollback plan should exist?

A rollback plan should name the exact script, owner, scheduler, credential, and last known-good output. For EWS migrations, rollback cannot rely on EWS after Microsoft disables it, so the real rollback is usually switching from one replacement path to another: Graph direct, connected Exchange grant, or Agent Account sender.

Document the cutoff date with absolute dates: October 1, 2026 for the start of Exchange Online blocking and April 1, 2027 for full disablement. Any rollback plan that depends on EWS after April 1, 2027 is not a rollback plan; it is a reminder that the migration started too late.

Next steps

• EWS to Microsoft Graph migration -- deeper timeline, auth, and feature-gap mapping
• List Exchange emails from terminal -- verify inbox access without EWS
• Manage Exchange calendar from the CLI -- test calendar access before migration
• Send-MgUserMail vs Send-MailMessage -- choose a modern PowerShell send path
• Email list command -- exact flags for the first Exchange smoke test
• Calendar events list command -- exact flags for calendar migration checks
• Full command reference -- every flag and subcommand documented