Still Running, Still Billing: Inside the Fortune 500's Quiet, Comfortable Life on Internet Explorer
Photo: corporate office server room IT infrastructure enterprise technology data center, via img00.deviantart.net
Somewhere in a glass tower in midtown Manhattan, a financial analyst is running an internal risk management platform that hasn't been touched since the Obama administration. It loads in IE11 compatibility mode. It works perfectly. Nobody is losing sleep over this.
Somewhere in a hospital system in the Midwest, a nurse is accessing a patient records interface through a browser wrapper that is, technically speaking, Internet Explorer under the hood. The interface loads, the records appear, the care gets documented. The hospital's IT director is aware of this situation. He has a spreadsheet about it. The spreadsheet is color-coded.
And somewhere in a federal government building in the DC metro area, a contractor is running a procurement system on infrastructure that was certified and approved during a different technological era and will not be recertified without a budget allocation that has been pending since the last administration. The system works. The contractor gets paid. Everyone goes home.
This is the quiet, undocumented afterlife of Internet Explorer — and it is considerably more comfortable than the browser's public obituaries suggested.
The Industries That Didn't Get the Memo
When Microsoft officially retired IE in June 2022, the tech press treated it like a funeral. There were retrospectives, there were memes, there was a genuine outpouring of emotion from developers who had complicated feelings about a browser that had defined — and occasionally destroyed — their careers.
The enterprise sector mostly didn't notice.
Banking and financial services remain the single largest holdout category. The reasons are structural rather than sentimental. Core banking systems, trading platforms, and regulatory reporting interfaces were built to exacting specifications during a period when IE was the mandated corporate browser. Changing them requires not just development work but regulatory re-approval, security re-certification, and in some cases, examination by federal oversight bodies. The cost-benefit math rarely works out in favor of modernization unless something is actively broken.
"We have a position management system that was built in 2007," says Robert, an IT director at a regional bank in the Southeast who agreed to speak with us on background. "It runs on IE11 compatibility mode. It has never had a security incident. It does exactly what it's supposed to do. The cost to replace it would be in the seven figures and would require six months of parallel testing during which we'd be running both systems simultaneously. For what? So we can say we're on a modern browser?"
Robert's color-coded spreadsheet, it turns out, is a risk register. IE-dependent systems in green are stable and low-priority. Yellow means they're due for review in the next budget cycle. Red means something is actually causing problems. His spreadsheet is mostly green.
Healthcare's Particular Flavor of Legacy
Healthcare is where the IE legacy story gets most interesting — and most defensible.
Electronic health record systems, medical device interfaces, and clinical workflow applications are subject to FDA oversight and HIPAA compliance requirements that make casual software updates genuinely risky. A browser update that changes rendering behavior can, in theory, affect how a clinical interface displays medication dosages or lab results. This is not a hypothetical risk that compliance officers invented to avoid work. It is a real concern that has produced real caution.
The result is that many healthcare organizations run a bifurcated browser environment: modern browsers for general use, and a carefully controlled legacy environment — often IE11 or an IE-based wrapper — for clinical applications. The clinical environment gets tested, certified, and then not touched until there's a specific reason to touch it.
"The phrase I use with my team is 'if it's not broken, document why it's not broken,'" says a healthcare IT manager in Chicago who declined to be named because her organization's legal team has opinions about press coverage. "We know exactly which systems run in compatibility mode. We know exactly why. We have a remediation roadmap. The roadmap has been on the books for three years. We'll get to it."
The roadmap, she acknowledges, is also color-coded.
Government: The Final Frontier
Federal and state government systems represent perhaps the most extreme version of the IE retention story — and also, arguably, the most rational one.
Government software procurement operates on timelines that would be unrecognizable in the private sector. A system that takes three years to specify, two years to procure, and two years to implement is not unusual. By the time it launches, it may already be running on infrastructure that the commercial web has moved past. By the time it's due for replacement, it may be running on infrastructure that the commercial web has forgotten entirely.
This isn't dysfunction, exactly. It's the inevitable result of applying procurement rules designed for physical infrastructure to software. The rules exist for good reasons — transparency, competition, accountability. They produce timelines that are incompatible with the pace of browser development.
The result is government systems that run in IE not because anyone prefers this but because the replacement cycle hasn't come around yet and the system, frustratingly, continues to work.
The Rational Case for Not Fixing What Isn't Broken
Here's the uncomfortable truth that the tech industry's modernization narrative tends to skip over: legacy systems that continue to function correctly are not problems. They're assets.
A financial system that has processed transactions accurately for fifteen years has a track record. A clinical interface that has displayed patient data without error for a decade has a reliability history. These are not things to be casually discarded in pursuit of technical currency.
The organizations keeping IE alive in 2024 are not, by and large, doing so out of ignorance or laziness. They're doing so because they've run the numbers and concluded that the risks and costs of migration outweigh the benefits of modernization — at least for now, at least for these specific systems.
Is this a permanent state? No. Every IT director we spoke with has a roadmap. Every roadmap has a timeline. The timelines are longer than developers would like, but they exist.
The Developers Caught in the Middle
The people who bear the actual cost of enterprise IE retention are the developers assigned to maintain, extend, or interface with these legacy systems. They're the ones learning IE quirks in 2024. They're the ones running virtual machines. They're the ones explaining to junior colleagues why this particular form validation uses a technique that MDN stopped documenting years ago.
Most of them have made their peace with it. The work is steady, the expertise is specific enough to command decent rates, and there's a particular satisfaction in keeping something ancient and complicated running smoothly.
"I've been maintaining this system for six years," says a contractor in Northern Virginia who works on a federal procurement platform. "I know it better than anyone. When it eventually gets replaced, that knowledge disappears. Until then, I'm the person who keeps it running. There are worse things to be."
He pauses. "The IE debugging still gets me sometimes, though."
Internet Explorer Tan understands completely. We're still loading too.