Microsoft is switching off the EWS API. Here’s how we’re moving forward, and what you need to do.

BackupAssist 365 has been happily using the Microsoft EWS API for many years, but how we back up email will soon change because Microsoft is retiring the EWS API.

The good news is that over the last 6 months, we’ve been working on a new design and architecture for mailbox backups that will last the next decade and beyond. The result is faster, more secure backups, and more precise restores.

The bad news is there’s a little administration work needed to keep the backups running as Microsoft switches off their EWS API.

In this post, I’ll cover:

• Some recommended steps to keep BackupAssist v1 running for another 8 months. (It takes under 5 minutes.)
• A sneak peek at BackupAssist 365 v2, which we are preparing for beta testing very shortly.

Part 1 – keeping BackupAssist v1 running

A 5 minute procedure will keep BackupAssist v1 running. Here are the key dates:

Microsoft’s own notice has the full timeline and explanation.

What you should do by 31 August 2026

We recommend that you extend EWS, just to avoid potential backup downtime. This is an IT admin task, so you’ll need Exchange admin permissions and the Exchange Online PowerShell module installed.

# One-time setup, if you don't already have the module
Install-Module -Name ExchangeOnlineManagement

# Connect to your tenant
Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com

# Check your current EWS status
Get-OrganizationConfig | Format-List EwsEnabled

# Enable EWS explicitly at the tenant level
Set-OrganizationConfig -EwsEnabled $true

# Check your EWS status got updated
Get-OrganizationConfig | Format-List EwsEnabled

If you perform the task by 31 August 2026, you’re safe – backups will continue to run with no interruption.

If you don’t make the 31 August 2026 deadline, don’t panic. The situation will be recoverable, and we will release a simple tool to restore backup operations. We just can’t build the tool yet because we have to see Microsoft’s actions first. There may be one or two days of backup downtime if Microsoft switches off your EWS API and then we have to switch it back on.

Part 2 – How BackupAssist 365 v2 will improve your mailbox backups

There are two key technical changes in BackupAssist v2:

1. API change: it uses the Microsoft Graph API in place of EWS
2. Data format change: it uses a SQLite database instead of PST files to store data

Although the net result of these changes has been extremely positive, initially we weren’t pleased to have to switch APIs and throw out a lot of existing code. We put in countless hours working around the many, many bugs in EWS. EWS is extremely fickle, with probably hundreds of edge cases from throttling to incorrect error messages.

But it’s turned out to be a blessing in disguise. The change in API has prompted us to make significant upgrades to our mailbox backup engine.

While we were designing around the new API, we realized that this was the ideal time to reconsider our overall backup architecture and look for improvements. Switching APIs is a big task, so given we had to rewrite our mailbox backup “engine” anyway, it’s the ideal time to upgrade everything else around it. And what we’ve come up with is even better in terms of:

• Performance – significantly faster incremental backups via delta query
• Long term accessibility – from a Microsoft file format (PST) to the SQLite file format which is truly public domain
• Data security – from only password protecting a PST file to now fully encrypting all data at rest

There’s one significant change I must highlight – we’ll no longer use PST files as our storage format.

Why we didn’t just point the old PST format at the new API

Graph API and EWS don’t map onto each other cleanly. Graph gives us fields EWS never had — Focused Inbox classification, Teams meeting links, direct webLinks back into Outlook. EWS gave us raw MAPI properties that Graph doesn’t expose the same way. Two APIs built a decade apart, describing the same mailbox differently.

We could have forced the new fields into the PST file using custom data fields, but it wouldn’t have been wise or forward thinking. Microsoft has added so much functionality in recent years, we would expect more new fields over time – jamming them into the aging PST file format would be a compromise that gets worse over time.

What we built instead

Every mailbox now gets its own SQLite database — a single file per user, just as with PST files. But unlike database servers like Oracle or SQL Server, SQLite is extremely lightweight: no service to install, no DBA or licensing fees. And it’s even lighter than a PST – a blank PST is 265KB before it holds a single email; a SQLite file with the same schema in place is about 8KB.

We also keep every field that the Graph API returns, including any new ones they add later, so we’re now futureproof. A Microsoft API change doesn’t mean waiting on a BackupAssist update to avoid losing data. Backups after the first are incremental, pulling only what’s changed. Mailboxes are properly encrypted with AES-256, not PST’s cosmetic password. And there’s no massive performance hit when PST files get large.

Is a SQLite database a step backward for data sovereignty?

When our senior engineer proposed using SQLite as the storage format, I was nervous that we might lose the accessibility advantages of PST files.

But two things convinced me this was the right move.

First: there’s no genuinely open standard sitting there waiting for this data. Formats like EML were designed in the 1980s, long before Focused Inbox or a Teams meeting link existed. Even Exchange itself has drifted from the RFCs it’s nominally built on. Someone has to define a structure for this data, and whoever does, you’re trusting them to keep it stable.

Second: SQLite is open and public domain. Its developers have publicly committed to keeping the file format backward-compatible through 2050, and the US Library of Congress recommends it as a format for long-term digital preservation. That’s about as strong a vote of confidence as a file format gets from outside its own project.

SQLite databases are self-describing. Open one with a free tool like DB Browser for SQLite and the schema is right there — no separate spec to track down, unlike PST’s dense format documentation.

And it’s AI friendly! If you’d rather ask plain-English questions of an old backup than write SQL, that same self-describing schema means an AI model can do that too. In fact, I will record a video demonstrating how easy it is to feed a mailbox backup into AI to do virtually any kind of search and retrieval you could ever want.

What this means for you

The one drawback that we couldn’t overcome

There’s one drawback that we tried to address, but simply couldn’t. There’s unfortunately no migration path between the old and new data formats.

If you’ve got PST-based mailbox backups already on disk, you’ll need to set up a new backup job and re-download your mailboxes. We recommend you archive your existing backups somewhere safe, then let BackupAssist download each mailbox afresh under the new format. It’s a one-time hit but the benefits will be ongoing.

So when you’re ready to upgrade: archive your existing PST-based backups permanently, and then set up a mailbox backup. The initial download will, unfortunately, be slow. But thereafter, every backup after that is incremental again, and considerably faster than before.

Feedback

We know that a major change like this causes extra work and inconvenience – which is why we prefer not to make major changes at all!

Do you have any concerns – say about the new data format? Is there a use-case we need to know about? Please contact our support email address with any feedback you have.

In the meantime – happy backups.