Referencing this [closed] bug report:
Do we have a migration path in 2026? I know some part of the Graph API has been implemented but it seems that it is not feature complete when compared to EWS.
The Thunderbird people have this:
Any opportunities here to work together? Just wanted to see where we are before Jan 2026 happens and we have to handle deluge of “hey it isn’t working” and reduce stress and load on maintainers by communicating early.
Microsoft blog link:
It’s good they set a deadline and hopefully they will extend the deadline to accommodate the fact that graph is not feature complete against ews.
Hi,
I’m not sure I understand the above properly. Do you mean the features
implemented by the evolution-ews projects using the Microsoft Graph API
is not feature complete to what the Exchange Web Services protocol
implementation in the evolution-ews does, or you mean the Microsoft
Graph API is not feature complete with the EWS protocol (aka on the
server)? One cannot do anything with the later.
I do not know how Thunderbird’s EWS implementation is of any help here,
EWS will be disabled for the outlook.office365.com. It’ll still work
for the on-premise Exchange servers (where the Graph API is nonexistent
as far as I know). The internals of the Thunderbird and Evolution are
incompatible, thus any code sharing is kinda out of question.
The evolution-ews project offers both “Exchange Web Services” and
“Microsoft 365” account types. The best thing you can do is to install
the latest upstream stable version (the distros can lack behind, thus I
really mean the upstream version; the bug you referenced was closed
more than a year ago, many fixes had been done for the m365 meanwhile,
it’s in much better shape than the year ago) and give it testing. There
are missing features, there are bugs in the code, but filling them
early will allow early fixes. Some problems are due to the protocol
limitations though.
Bye,
Milan
There is regulator attempt to share messages between Android and Apple phones, so WhatsUp and similar could make appear on native system applications but that it is also corporate environment issue if allows such things and Exchange is well know to be incompatible and make it incompatible as it is lock vendor feature…
MS Graph is a lot wider area including access to account and private corporate informations so limited access(or various levels access) is in void for third party’s environments…
But todays reality is also Zappier and similar like Kestra, so there is more appetite for something similar than simply make webdav server and make it environment standard with corporate issues on the flow with Microsoft attempts to block hackers with global GNOME access permission…
This topic is about EWS and Graph API. It’s not about random other unrelated technologies out there.
Evolution (and EWS AFAIK) have nothing to do with instant messaging,
which is what these regulator measures are addressing.
poc
I meant the latter. So in 2026, we’d move to the graph api in evolution then but it won’t have the same experience?
For thunderbird, I was thinking they could break it out as a separate library that we could use. Of course, it’s in rust so that itself would be a challenge. Just looking for ways that we could leverage work of others than trying to do it ourselves.
Ultimately, I want to make sure we share comms with downstreams and the public since the evo + ews plugin is used extensively.
So in 2026, we’d move to the graph api in evolution then but it won’t
have the same experience?
Hi,
the protocols are different, the experience will be different. Or not
that different, not in the evo itself. It’s understood that the feature
parity will be good to have, as long as the new protocol has a
counterpart for it. An example, there is no Global Address List (GAL)
in the Microsoft Graph API.
For thunderbird, I was thinking they could break it out as a separate
library that we could use.
The post you provided is about the EWS protocol, the one which a) evo-
ews has implemented in a very good shape; b) is going to be disabled in
the online Exchange. The post mentions they are not going to do the
Microsoft Graph API at the moment. Making their code a library would be
useless. Their library would also fit their architecture, which is way
different from the evo-ews. The evo-ews has currently much better
support for the Microsoft Graph API than the Thunderbird (which has
zero), thus the opposite would make more sense, have the evo-ews expose
the Microsoft Graph API as a library, but a) evo-ews depends on the
evolution and evolution-data-server; you do not want to install both
when you want to use Thunderbird or any other client; b) the
architecture is different between the projects.
In other words, the cooperation would be nice, but it’s close to
impossible. The only bits which could be shared are those under the
common/ directory, and in there only the connection and the json utils
code, something what they can easily build on their own with their own
preferred programming language.
As I said earlier, if you want to help, then install the latest
upstream version of the evolution-ews, configure a “Microsoft 365”
account and use it. Fill bugs here [1], thus it can be fixed and
enhanced early. The things I test and run here can work for me, but not
in the real life environment, as shown for example here [2]. You can
use a Flatpak version, which runs independently from the host system
version, thus you can run it only for testing purposes (unless you
already use a flatpak version, of course). Some information about
building evo in the Flatpak on your own, from the latest upstream
sources, is here [3].
Bye,
Milan
[1] Issues · GNOME / evolution-ews · GitLab
[2] Organization contacts not shown (#285) · Issues · GNOME / evolution-ews · GitLab
[3] Evolution in Flatpak · Wiki · GNOME / evolution · GitLab
OK, Milan - thank you. 
When we get close to the swtichover - let’s chat about how we could communicate that so that there is less work for us on comms.
(we use evo at work extensively)
Perhaps you could do a talk at Linux App Summit in regards to all this? Mail clients are a big deal these days.