It's not really about all those enterprise-y intranet sites that "only" work on IE6. It's likely that the amount of effort necessary to make those sites work on IE8 is, on average, not that great. The problem is more the environment those sites were created in. Hidebound, fear-based bureaucracy combined with very little development talent.
Most such sites are burdened by crushing change-control processes. Those change-control processes exist as a somewhat reasonable bulwark against the very real harm that an unskilled, talentless development team (which, sorry to say, is the norm in the enterprise) lead by unsophisticated, incompetent management can do. This creates a double-whammy for corporations who want to move away from IE6. In principle the work may not be that difficult or extensive, but the dev. team may be too incompetent to even be aware of what the right work is or what the risks are, and the testing process alone would be extremely costly and time consuming. Not to mention the tricky cross-coordination between multiple teams that may be required. It's a perfect storm of just the sorts of things that can halt enterprise-y organizations in their tracks.
Note that the even bigger problem of updating all of the sites on the web so they worked in more modern browsers (even back in the day a multi-billion dollar problem) has already largely been solved. Because site owners knew they had no choice so they rationally invested enough effort into keeping up with the times as was necessary. It's not the size of the problem, it's the capability of the people and organizations tasked with solving it that's the problem.
I've seen lot of things, but still never encountered one of these rumored 'enterprise IE6 only intranet'-apps. Do these things really exists? And why have they not been rewritten yet? These things must be 10+ years old. I rewrote couple internal apps that were a mess of php tucked together with mysql.. they worked.. but hell.
If I'll come across one of these IE6 apps, I'll be the first one to lobby for a rewrite.
They exist. They are payroll, timesheet, and scheduling apps built in the early days of javascript and css when cross-browser compatibility was much harder, and sold to companies who has IE 4 or 5 or 6 on all machines anyway, so what's the big deal if it doesn't work in Netscape?
I'm sure even the people who wrote them never imaged they'd still be in use ten years later.
Yes, they do unfortunately. Often they are relics of some old homespun solution no one understands and everyone is afraid to touch, maybe a product of a dead company, or simply ancient versions that haven't been upgraded in eons because it's cheaper and easier to keep IE6 installed.
The lingering of IE6 is not inherently a "hidebound bureaucracy" problem (though hidebound bureaucracy doesn't help), and has little to do with "crushing change control processes". It's the natural consequence of a number of very sensible business decisions.
If you're developing internal-facing web apps in an enterprise with 15k+ desktops, all of which run a known software stack that includes IE6, your apps are going to target IE6. There's no reason not to -- even if company policy allows folks to install Opera or Netscape on their own, support for those browsers isn't in your project requirements and it isn't in your budget. You aren't necessarily going to INTENTIONALLY do things that ONLY work in IE6, but you aren't going to go out of your way to avoid them either. And if there are IE6-only features, add-ons, ActiveX controls, etc. that make your application work better/faster/etc., you KNOW FOR A FACT THAT YOUR ENTIRE AUDIENCE CAN RUN THEM, so you're going to take advantage of them.
Then Microsoft sits back and enjoys their "win" in the browser wars. So your org has five years -- 2001-2006 -- to develop apps that assume IE6 as the native operating environment.
Big companies can churn out a lot of internal-facing web applications in five years.
Then Microsoft wakes back up and announces that IE7 is on the way -- time to start planning the upgrade. And here's where everything goes to hell in a handbasket: IE7 is not designed to coexist with IE6. You can run one or the other, but not both. (There are hacks that let you get around this, but you don't last long in enterprise desktop software management by encouraging people to run critical business applications on a scaffolding of "hacks".)
So this is what your company's migration from IE6 to IE7 will entail:
* You can't just install IE7 because it'll break things. Probably critical things. If reps come in on Monday and can't take customer orders because you deployed IE7 over the weekend and its updated rendering engine has decided to display the payment field somewhere off the right-hand side of the screen, you will have Failed.
* So, developers need to regression-test everything in your company's portfolio of web applications to make sure they all behave sensibly in IE7's updated engine. Most probably require minimal remediation, but you can't assume that -- you have to check.
* EVERYTHING you develop between the start of the migration and the day IE7 hits your users' desktops either has to work in BOTH IE6 and IE7, or has to be held back from deployment until the day IE7 goes live. Which you can't do until you know everything important has been remediated.
* If an app needs major changes for IE7, any bugfixes and enhancements that can't wait for the IE7 launch have to be made in both the live source and the remediated source. You'd better have good source control practices, and developers who actually bother to follow them.
* Apps that can't easily be made to work well in both IE6 and IE7 have to be deployed at the same time as the browser rollout. One big Flag Day. Hope you didn't miss anything important, because if you did, rolling back to IE6 will not be pretty. And will break all the apps that were rolled out at the same time because they assume IE7.
* Multiply this by hundreds of applications, many of which probably haven't been touched in years, and whose original developers are long gone. (Your ASP.NET devs are probably LOVING having to root through all that legacy ASP Classic code!)
And here's the killer: all this time and effort and remediation is in service of a goal that HAS ABSOLUTELY NO DIRECT BENEFIT TO YOUR COMPANY'S BUSINESS OPERATIONS. Ultimately, people will be doing the same work in the same applications on Day IE7+1 as they were on Day IE7-1. Nobody's job is going to be made easier, no department's bottom line is going to see an uptick. There are second- and third-order benefits from the change (security, etc.) but they don't show up well on a balance sheet...maybe you're lucky enough to be in a company that values them anyway, in which case you have a nice win. But maybe you aren't.
Do you begin to understand why, under some circumstances, NOT replacing IE6 might be a reasonable decision?
I was one of those poor bastards in a corporate IT department six or eight years ago arguing passionately that the standards were in the RFCs and not in "the way Microsoft does things" and we shouldn't design the intranet nor buy expensive products dependent on IE 6 nor rely on postback for GET requests nor etc., etc., and I was pretty consistently shouted down. Any schadenfreude I might enjoy now at the results of one or two particular projects I worked on are overshadowed by regret at missing what we could have done.
In such a situation your choices are either: buckle and become a cog; do it anyway and ask for forgiveness later, if anyone notices (good luck); get the eff out as fast as you can.
...and the poor slobs who got sold software that would only work via IE6.