If you are an IT admin and the phrase “Internet Explorer Mode” has not crossed your desk in the last week, it should. Microsoft put a hard expiration on the IE Mode compatibility layer inside Edge by the end of 2029. The deadline is not a rumor, not a roadmap slide, and not a soft target. It is in the Microsoft 365 admin center, in language polite enough that most people read past it. The reason it matters, and the reason most teams will sleep through it, is that the apps depending on IE Mode are the ones nobody has touched in years. They live in the corner of every org’s IT estate where the last person who understood them retired in 2022.
The interesting bit is not the retirement. Microsoft has been telegraphing this since 2021. The interesting bit is that nobody has been forced to count which apps in their environment actually depend on the Trident engine (the layout engine that powered Internet Explorer 11, also called MSHTML). Edge can keep opening pages that look fine and behave wrong. That is the failure mode that makes IE Mode dependency invisible until the day it goes away.
What IE Mode actually is, in language that does not require a history lesson
Edge is a Chromium browser (Chromium being the open-source engine that powers Chrome, Edge, and most modern browsers). On top of the modern Chromium layout engine, Microsoft also ships the old Trident engine inside Edge. When a website, an internal app, or a vendor portal tells Edge “I need Internet Explorer,” Edge flips into IE Mode and renders that one page using the Trident engine. To the user, the chrome around the page still looks like Edge. The address bar, the tabs, the bookmarks. Only the rendering engine under the hood changes.
The reason this matters in 2026 is that a non-trivial number of line-of-business apps were built assuming Trident was always there. Old ActiveX controls, custom form behaviors, certain Java applets, certain CSS layouts that depend on the box model that Trident used to ship. Most users never see this. They open the vendor portal, the page loads, a button does not quite behave right, and they assume the vendor’s portal is buggy. Sometimes it is the portal. Often it is the engine.
Microsoft retired the standalone Internet Explorer browser years ago. They kept the engine alive on purpose inside Edge, because the cost of asking every business to rewrite their old apps was higher than the cost of carrying the engine. That calculation worked in 2021. It works less well in 2026, when Chromium has moved forward several major versions and carrying Trident gets more expensive every year.
Why 2029 is closer than it sounds
A three-year runway sounds generous until you have done a legacy app migration. The sequence, in order, is roughly:
- Inventory which apps, portals, or workflows touch IE Mode. Pull the actual usage data from your Edge management policy if you have one. The data is sitting in your tenant.
- For each app, decide the fate. Refresh the existing app to use modern standards. Replace the vendor. Rebuild the workflow somewhere else. Or, in the rare case where none of that is realistic, document the risk and accept the borrowed time.
- Negotiate with vendors whose apps depend on IE Mode. Some of them have modern versions on a roadmap. Some of them will tell you they do not, which is its own kind of information.
- Budget for both the audit and the rebuild. They are usually billed separately, because the audit is small and the rebuild is large, and the people who control each budget are often different.
- Test the new version against the workflows that have not been touched in years, because that is where the surprises live.
The reason this matters right now, in mid-2026, is that the audit step is the one everyone skips, and it is the only one that gets more expensive the longer you put it off. A vendor that has a modern version in 2026 might lose interest in 2028. A custom app whose last maintainer is about to retire is a custom app that gets harder to migrate every quarter. Microsoft learned this lesson the hard way with past retirements, which is why they sent the reminder through the admin center in the polite warning language that says, in corporate translation, “we have watched too many teams find out about these deadlines the week before they hit.”
How to know if any of your tools actually depend on IE Mode
The fastest audit method does not require an inventory project. It requires an Edge tab and ten minutes.
- Watch the rendering engine indicator. Open Edge, hit Ctrl+Shift+I to open DevTools, then go to a suspect page. Look at the top of the rendering engine indicator. If it says “Trident” or mentions IE Mode in the engine string, that page is loading under the old engine. If it says “Blink” or “Chromium,” you are on the modern path.
- Survey your staff. The people most likely to hit IE Mode pages are in finance, HR, operations, and any team that logs into a vendor portal on a regular cadence. Ask them if any of their tools look weird. They will tell you, because they have already noticed.
- Check your Edge management policy. Most enterprise tenants log IE Mode sessions. If your admins care about reporting, the data is already there. Pull a usage report for the last 90 days.
- Ask your vendors directly. Not “do you support IE Mode,” because they will all say yes. Ask “what is the timeline for dropping IE Mode from your portal.” The answer to that question tells you how much runway you really have.
If none of those checks light up, you probably do not have an IE Mode dependency and the 2029 deadline is somebody else’s problem. Most small and medium businesses that already moved their core workflows into a SaaS tool will not notice the retirement. That is the population Microsoft is not worried about. The population Microsoft is worried about is the schools, hospitals, factory floors, municipal offices, and small businesses that bought software more than a decade ago and never had a reason to think about the rendering engine under the hood.
Trade-offs
The honest cost of doing this audit now is that it surfaces work. The inventory will turn up at least one tool that depends on IE Mode and that nobody has a clean migration plan for. That is the whole point of doing the inventory, but it is not free. Once the dependency is visible, you cannot un-see it, and someone has to budget for the rebuild.
The cost of not doing the audit is that the work shows up in 2028 or 2029, on a timeline you do not control, with vendors who may or may not be helpful by then. Doing the audit now lets you sequence the migrations across the next three years and pick the vendors you actually want to keep. Not doing the audit forces you to do everything at once, which is the path that turns a one-year project into an eighteen-month project that misses its deadline.
There is also a tradeoff in the App Assure program, which is Microsoft’s free compatibility service for Microsoft customers who hit modernization headaches. App Assure is genuinely useful and most IT teams have never heard of it. The cost of using it is mostly organizational, in that you have to engage with a Microsoft account team and document the workflow you are migrating. For a small shop without an enterprise agreement, the engagement overhead can outweigh the technical help. For a mid-market or enterprise team, App Assure is one of the better free things Microsoft offers.
What I would tell past me
Three things, if I could send them back.
- Audit the rendering engine, not the URL. A page that loads is not evidence the engine is modern. The only honest signal is the engine indicator in DevTools or the IE Mode usage log in your tenant.
- Assume every long-running vendor portal depends on the old engine until proven otherwise. Tools that nobody has touched since 2018 are exactly the tools that have not been rewritten. Verify, do not guess.
- Do the inventory in 2026, not 2028. The work is the same either year, but the room to sequence and negotiate is much wider when the deadline is still three years out.