Version 2 of BackupAssist 365 (which is currently in beta testing) changes how we back up email, because Microsoft is retiring the EWS API underneath us. But this has been an opportunity to reevaluate our design and architecture to make sure it lasts the next decade.
Key dates:
| Date | What happens |
|---|---|
| Prior to 31 August 2026 | Admins who still require EWS can extend its availability using a PowerShell command (explained at the bottom of this blog) |
| 1 October 2026 | Microsoft starts disabling Exchange Web Services (EWS) by default across Exchange Online, unless the extension was set up |
| 1 April 2027 | EWS is fully and permanently shut down |
Microsoft’s own notice has the full timeline. If you need a little time to test BackupAssist 365 v2, we recommend extending EWS as an interim measure.
Either way, BackupAssist 365 v2 moves off EWS onto Microsoft Graph API for good.
I have some recommended action steps at the bottom of this blog – but first let me describe some of the engineering decisions.
The change in API has prompted us to make significant upgrades to our mailbox backup
While we were designing around the new API, we realised 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
Let me explain some of the engineering changes.
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 like how it was with PST files. But unlike database servers like Oracle or SQL Server, SQLite is extremely lightweight: no service to install, no DBA, no licence to buy. 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?
Fair question. If your reaction is “wait, isn’t a database exactly what you’ve told me to avoid for years,” it was mine too, for a while.
Two things settled it for me.
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 has been doing exactly that since 2000. It’s public domain — no licence, no vendor, no patent to track down. 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
| Old: PST over EWS | New: SQLite over Graph API |
|---|---|
| Missing newer Microsoft 365 fields | Every field Microsoft returns, including future ones |
| Differential backup – item header comparison every backup | Incremental at API level — only fetches what’s changed |
| Password that only looks like protection | Real AES-256 encryption |
| Performance degrades past ~50GB | No practical size ceiling |
| No reliable tracking of moved or deleted items | Move detection and full historical tracking |
The catch that we couldn’t work around
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 archiving your existing backups somewhere safe, then let BackupAssist download each mailbox fresh under the new format — it’s a one-time hit but the benefits will be ongoing.
What you should do
1. Extend EWS, if you need more time. 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
# Allow the specific applications that still need EWS access (replace with your actual application IDs)
Set-OrganizationConfig -EwsAllowedAppIDs "app-id-1,app-id-2"
Do this before 31 August 2026, or your tenant gets auto-disabled on 1 October (recoverable, but with a brief interruption while you sort it out). Full detail is in Microsoft’s own documentation.
2. Try BackupAssist 365 v2 on a separate machine. Get familiar with the new system and features before it touches your production backups.
3. When you’re ready to upgrade: archive your existing PST-based backups somewhere safe, then set up new mailbox jobs. There’s no migration path from the old format to the new one — this is a fresh start, not a conversion, so the first backup under v2 is a full download for every mailbox. Every backup after that is incremental again, same as 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.
