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?
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?