IE mode dependency
Your application only works in Internet Explorer mode
It's a solvable engineering problem with a known cause, not a cliff edge.
Thousands of business-critical applications still require Edge's IE mode to function: Classic ASP sites, ASP.NET WebForms applications, anything built against ActiveX controls or VBScript. If yours is one of them, this page covers what actually causes the dependency, how much time you genuinely have, and what it costs to remove.
First, the deadline
IE mode is not being switched off next year. Something else in your building has a real date on it.
If a vendor or an internal memo has you treating this as an emergency, it is worth getting the timeline straight before you spend anything.
Internet Explorer 11 as a desktop application was retired in June 2022. IE mode inside Microsoft Edge is a different thing, and Microsoft has committed to supporting it through at least 2029, with a year's notice before it is retired. Many organisations started looking at this because Microsoft asked administrators to begin mapping their remaining IE dependencies. That is a request to plan. It is not a cut-off.
Meanwhile, if that application is sitting on Windows Server 2012, the paid Extended Security Updates for that operating system ended in October 2026, which means no security patches at any price. In almost every engagement we take on, the server is the urgent problem and the browser is the visible one.
- Plan on your schedule, not a panic. You have years, and that means you can fix this properly and cheaply rather than urgently and badly.
- Do not let it justify a rewrite. An IE dependency is a reason to remove an IE dependency. It is not evidence that the application needs replacing.
- Find out what you actually have first. The cost range between a tidy dependency and a deep one is enormous, and a day of investigation tells you which you own.
- Fix the server question in parallel. The two pieces of work are largely independent, so neither has to wait for the other.
What actually causes it
"It only works in IE" is always one of a short list of specific things.
After twenty years of this work, the causes are familiar. These are the ones we find, roughly in order of how often they turn out to be the real answer.
Browser definition files
In ASP.NET, an App_Browsers folder or a stray
.browser file tells the framework what each browser can handle.
When the definitions predate every modern browser, the framework decides Edge
and Chrome are primitive clients and emits deliberately downlevel markup to
them. The application then genuinely is broken outside IE, for a reason that
has nothing to do with the application's own code.
This is the happiest finding available, because it is usually a configuration fix rather than a code change.
- App_Browsers
- .browser files
- clientTarget
ActiveX and COM in the page
Scanner integrations, signature pads, label printers, document viewers, PDF controls and the old reporting toolkits were all commonly built as ActiveX. No modern browser will ever load them. Where the control talks to hardware on the user's desk, the replacement is a small local service or helper application that the browser talks to over HTTP instead.
This is the category that costs real money, and the one worth identifying early.
- ActiveXObject
- clsid:
- <object> tags
- FileSystemObject
Modal dialogs
window.showModalDialog was the standard way to open a blocking
popup that returned a value to its parent, and a generation of line-of-business
applications used it for every lookup, picker and confirmation. No browser but
IE supports it now.
The fix is well understood and the work is mechanical: a dialog component plus a callback in place of a return value. The cost is simply however many call sites there are, which is why counting them is the first thing we do.
- showModalDialog
- dialogArguments
- returnValue
IE-only JavaScript
document.all instead of getElementById,
attachEvent instead of addEventListener,
window.event read as a global, Msxml2.XMLHTTP created
through ActiveX instead of XMLHttpRequest, and conditional comments
branching the page by browser.
Individually trivial. The question is only how many there are and how deeply the patterns are woven into shared include files.
- document.all
- attachEvent
- window.event
- Msxml2.XMLHTTP
VBScript in the browser
Client-side VBScript only ever ran in Internet Explorer, and Microsoft has
retired it from Windows itself. Where a page contains
<script language="vbscript">, that code has to be rewritten
in JavaScript. There is no compatibility layer and there never will be.
Worth separating clearly from server-side VBScript, which is what Classic ASP is written in and which is not affected by any of this.
- language="vbscript"
- MsgBox
- Set objects
Rendering and layout assumptions
An X-UA-Compatible header pinning the page to IE 7 or IE 8
document mode, quirks-mode layout that only holds together under the old box
model, framesets, and CSS written against IE's own filters and expressions.
Usually the least alarming category and the most tedious, because it surfaces as a page that loads perfectly and looks wrong.
- X-UA-Compatible
- quirks mode
- <!--[if IE]>
- filter: progid
None of these require guesswork. Every one leaves a specific, searchable fingerprint in the source. An audit is not an opinion about your application, it is a count: how many call sites, in which pages, of which kind. That count is what turns "nobody knows how big this is" into a fixed price.
What it costs
The honest range is wide, and a day of work tells you where you sit in it.
We classify every finding into one of these three before quoting anything, because the difference between them is the difference between a week and a quarter.
Configuration only
Browser definition files, a document-mode header, a handful of conditional comments. The application is fine and has been telling the browser to behave badly. Days, not weeks, and no change to how anything works for the people using it.
Mechanical code work
Modal dialogs, IE-only event handling and DOM access, VBScript in pages. Individually simple, repeated across a lot of files. Predictable, quotable at a fixed price, and the bulk of most engagements. This is where an AI-assisted pass over the codebase genuinely changes the economics.
Hardware and ActiveX
A scanner, a scale, a label printer or a signature pad reached through a control no browser will load. Each one needs a replacement path designed and tested against the actual device. This is the category that deserves its own decision, and sometimes the right answer is to leave that one screen in IE mode and move everything else.
The uncomfortable possibility: occasionally the audit finds that the dependency is shallow and someone has been quoting you a rewrite to fix it. We would rather tell you that and lose the larger engagement than take the money.
How we do it
Audit first, at a fixed price, and the report is yours either way.
You should be able to find out what you are dealing with without committing to the work, and without committing to us.
-
Inventory every dependency
We take a copy of the source and search it for every known IE fingerprint, then read the results rather than just counting them. The output is a table: file, line, what kind of dependency, and what it would take to remove. Nothing is installed on your systems and nothing is changed.
-
Walk the application as your staff do
A grep finds code. It does not find the workflow that silently fails on step four of an order. We go through the significant journeys in a modern browser and record exactly what breaks and where, because that list is what the business actually cares about.
-
Classify and price
Every finding lands in one of the three categories above, with an effort against it. You get a written assessment with options and costs, and you own it. Take it to another firm if you would rather.
-
Fix in increments, verified against the original
Work goes in a slice at a time, each slice deployed where you can use it and checked against the behaviour of the existing system. Nothing is held back for a big reveal, and you can stop between slices and still be better off than when you started.
-
Prove it, then leave IE mode behind
The engagement is finished when your people do a normal day's work in a current browser and nothing surprises them. Not when the code looks right.
Common questions
The things people ask before they call.
Is IE mode really going away?
Not imminently. Internet Explorer 11 as a standalone desktop application was retired in June 2022, but IE mode inside Microsoft Edge is separate and Microsoft has committed to supporting it through at least 2029, with a year's notice before retirement. Treat this as work to schedule, not an emergency. If someone is selling you urgency, ask them for the date and the source.
Does fixing this mean rewriting our application?
Almost never, and we will say so even though a rewrite would be a far bigger engagement for us. An IE dependency is a set of specific, locatable things in the code. Removing them is surgery, not reconstruction. A rewrite is justified when the platform is genuinely unsupportable or the business has outgrown the design, which is a different conversation with different evidence behind it.
Our application is Classic ASP. Does it have to move to .NET first?
No. The browser dependency lives in the markup and the client-side script, and it can be removed with the application staying exactly where it is on Classic ASP. Whether you then want to port to ASP.NET Core is a separate decision with its own timing and its own business case, and it is usually better made after the urgent risks are off the table.
Nobody here knows how the application works anymore. Can you still do this?
Yes, and that is the normal starting point rather than an unusual one. Most systems we are handed have no documentation and no original author available. Reconstructing how something works from its source is the core skill we sell, and a browser dependency audit is one of the more tractable versions of it, because the thing we are looking for has a known shape.
We have a scanner that only works through an ActiveX control. Is that hopeless?
No, but it is the part to look at first, because it has the widest cost range. The usual pattern is a small local helper service on the workstation that owns the device and exposes it over HTTP to the browser. Sometimes the device's current manufacturer already ships exactly that. Occasionally the right answer is to keep that single screen in IE mode and move everything else, and that is a legitimate outcome rather than a failure.
How much does the audit cost?
It is a fixed price agreed before we start, scaled to the size of the application, so you know the cost of finding out. The remediation is quoted off the audit, which means you approve a number against a known scope rather than an estimate against guesswork.
Tell us what it does and what it's written in.
That's genuinely enough to start. We'll tell you what your realistic options are, including the ones that don't involve hiring us.