In many of the environments I work in, Office 2016 and Office 2019 are still running on a surprising number of endpoints. Usually these are older devices that have slipped out of normal lifecycle planning. The end of support for both versions on October 14, 2025 isn't news, yet people regularly underestimate what it means in practice. Missing security updates are only part of it. The bigger risk is that from that date, Microsoft no longer supports connecting these Office versions to Microsoft 365 services. The apps may keep working for a while, but if something breaks or stops being compatible, you're on your own.

Office 2016 and 2019 lose supported access to Microsoft 365 in October 2025

October 14, 2025 matters twice over. Office 2016 and 2019 leave extended support that day, and Windows 10 reaches end of life on the same date. Microsoft has been clear about this for a while (end-of-support overview, M365 services connectivity). After support ends you get no more security or bug fixes, and connectivity with Exchange Online, SharePoint Online or OneDrive for Business is no longer guaranteed. Things might technically carry on for a bit, but any change to protocols or authentication in Microsoft 365 could break access overnight.

That uncertainty is a genuine operational risk. In an audit or a compliance review, you can't justify running unsupported Office versions. Because Windows 10 support ends on the same day, you have an unusual opportunity to handle both migrations together and avoid doing the work twice. The organizations I've seen treat this as one modernization project ran into far fewer surprises and got less pushback from users.

A complete inventory shows where the old Office versions still run

Good planning starts with knowing exactly which Office versions are installed. If your devices are enrolled, the Microsoft 365 Apps admin center gives you an overview quickly. Intune is also fairly reliable, with version and edition details under Apps. If you still use Configuration Manager, a few targeted queries will find Office 2016 or 2019 installations without much effort. What surprises many teams is how many old MSI-based setups are still around long after everyone assumed they were gone.

Pro tip: Before you migrate at scale, take a full inventory of Office installations and compare it against your current licenses. That way you find shadow IT, outliers and forgotten legacy packages before they cause problems.

Putting the inventory results into a chart often helps people take the issue seriously. And once add-ins or macros come into play, the migration stops being an IT-only job, because business units and software vendors have a stake in it too.

Microsoft 365 Apps and Office LTSC 2024 serve very different needs

With support for Office 2016 and 2019 ending, the licensing question comes up straight away. Do you go with Microsoft 365 Apps (the cloud-connected subscription model) or switch to the perpetual-license track with Office LTSC 2024? The next LTSC release has been announced for the second half of 2024, with a fixed feature set and no cloud integration. In my projects, LTSC mostly makes sense for disconnected environments, heavily regulated use cases or applications with strict validation requirements. Most organizations, though, are already moving to Microsoft 365 Apps. That gets them regular feature and security updates and better integration, particularly with services like Copilot for Microsoft 365 (see also /blog/copilot-for-microsoft-365-tenant-readiness).

Microsoft 365 Apps gives you new features along with continuous security support. The latest collaboration and AI capabilities are only available there. LTSC still has its place for special cases, but I rarely recommend it as the standard anymore.

MSI removal and add-in compatibility cause most of the migration work

The technical side of the migration is seldom simple, especially when MSI-based Office installs are still sitting on endpoints. Microsoft strongly recommends removing MSI versions with the Office Deployment Tool before you roll out Microsoft 365 Apps. The configuration itself is short:

<RemoveMSI />

Most of the pain sits with add-ins, macros and custom integrations. On real projects I always set aside time for proper compatibility testing, above all for older COM-based add-ins and complex Excel or Outlook automation. Business-critical macros quite often break during an upgrade when they rely on deprecated APIs or on assumptions about how Office behaves.

This is a workflow I've seen work well in practice:

flowchart TD
    Inventory["Inventory Office versions"] --> Licensing["Decide on M365 Apps / LTSC"]
    Licensing --> Prep["Check add-ins & macros"]
    Prep --> RemoveOld["Remove legacy Office"]
    RemoveOld --> DeployNew["Deploy new Office"]
    DeployNew --> UAT["Test & validate"]

Figure: Typical workflow for migrating away from unsupported Office versions.

Once the migration is done, a structured round of functional testing, ideally with business users taking part, has spared my teams from post-upgrade surprises more than once.

The update channel deserves a deliberate decision

Picking the update channel for Microsoft 365 Apps is easy to skip until it starts causing trouble. Monthly Enterprise Channel fits most business environments that need predictability, while Current Channel works well for pilot groups and early adopters. The choice affects support and when features arrive. I cover it in more detail at /blog/microsoft-365-apps-update-channels-choose.

I would retire the legacy Office versions now

The end of support for Office 2016 and 2019 is not just a compliance footnote. If you haven't started planning the transition yet, start now. Windows 10 reaches its end at the same time, which gives you a good opportunity to modernize both in one go. In my experience, the projects that go smoothly are the ones with a clear inventory, careful compatibility testing and a considered update strategy. The payoff shows up in better security and tighter Microsoft 365 integration.