Microsoft Australia is currently driving a campaign where using Internet Explorer 6 is compared to drinking 9 year old milk. The by far biggest share of IE6 still used is in large enterprises. There are certainly many reasons why this is the case but in my opinion most of those reasons in one or another way are a direct result of specific circumstance which is

That Enterprises as well as small and medium businesses for the largest part do not have a browser strategy.

At least none that is independent from their client OS strategy. And the reason why most companies do not have an independent strategy is because Internet Explorer was shipped with Windows since Windows 98 with Internet Explorer 4 which is more than 12 years ago which again is centuries in IT terms. In addition, the importance of the browser as a productivity tool increased during those years with exponential rise over the last 5 or 6 years. Because of those circumstances many companies probably didn’t feel the urge to implement such an independent strategy. But because of not treating the browser as an independent part of the operating system most companies are still relying on Internet Explorer 6 which is already nine years old. In those 9 years however there were three different evolutionary streams. The first to name is the trend to implement more and more business applications as web applications which led to a huge amount of web applications within companies. And those were often optimized for the currently used browser (IE6). The second stream was the evolution of web technologies and web standards. The third stream was the growing number of attacks through web sites and also the growing numbers of attacking techniques including social engineering attacks. All three streams were heavily influenced and driven by the growing popularity and the rise of the web. So if you take this into account you could say that with the increase of the duration of usage of a specific browser version the ability to adapt and migrate decreases. This correlation is shown in the diagram below.

Critics now may say that this is all the fault of Microsoft because Microsoft is shipping IE together with Windows and Microsoft shipped IE6 flawed and forced the creation of web applications that introduced dependencies to those flaws. However those are reasons to from owns own complacency and indifference about treating the browser as an important productivity tool which needs to be treated like other mission critical applications or technologies in an enterprise. If Companies would have spent the browser the attention it deserved then there would have been plenty of opportunity to avoid the current situation because even Microsoft released two new browser versions which introduced great improvements in many browser relevant areas like security, standards, productivity features and performance compared to IE6. Those were released as stand-alone installers as well as part of Windows Vista or Windows 7. My theory is that they were simply neglected by enterprises because of a lacking independent browser strategy and omission. Although it seems like it I don’t want to scare anyone here because to be honest I think that the picture one my draw from the above would be way to negative because the ability to migrate will never be impossible and the efforts related to migration may be less than one would expect. I will elaborate about what I mean by that further down in this post.

Bottom line however is that the trends outlined above are some indicators that the browser is one of the most important tools in today's enterprise application landscape. This is not only my personal opinion but is also expressed by many respectable institutions and individuals. Forrester analyst Sheri McLeish for example said:

“Enterprises need to think about the browser as a productivity tool, not as a transparent application. They need to look at browsers more strategically.”

Another example is a citation of Andy Armagost, Birmingham Gas & Oil who said:

“The browser is one of the most important pieces of software we have right now”

And last but not least with ongoing increase of web applications, web services and especially now slowly starting move to cloud based services, the browser may become the single most important piece of software in the future. Which is a hypothesis that is also backed by Sheri McLeish:

“That IE6 is by far the most widely used browser among enterprises reflects most IT departments’ lack of interest in browsers. However, this laissez-faire approach toward browsers wouldn’t last long, he said. “The rise of software-as-a-service [SaaS] will force enterprises to at least come up with a browser strategy for their workforce”

With that all said it becomes obvious that - the time to act is now – it is time to do essentially two things:

• Start realizing the importance of the browser for the own company and define a independent strategy for it
• Start migrating to a current version of preferably Internet Explorer as it is still the best choice for deployment in corporate environments

I did not number these two tasks on purpose as they are probably almost equally important and because it is recommended to start doing both in parallel. As for the migration part still many companies, even those that may already have some kind of browser strategy discussion, are still in fear about the efforts and try to avoid the migration part. So I will try to give some, hopefully helpful, information on how one can get started, what else, apart from the above are the benefits of migration and about some determining factors relevant in the migration context.

1. Compatibility
   
   I will not reiterate what has been said many times about compatibility and its various facets with respect to Internet Explorer 8. Although it is super important there are enough sources, including this blog, where you can find information about it. As a starting point you can go to my respective article or the compatibility center on MSDN. Here however I want to point out that there are different kinds of compatibility of which some are important to reflect about when planning a migration process and its accompanying decisions and some that may be less or maybe even useless when deciding about what’s important to solve one’s personal or corporate compatibility question:
   
   1. Backward Compatibility or “Stand in for your heritage”
      
      Especially with an Internet Explorer focus I would define backwards compatibility as “Enabling correct functional execution and visualization of web applications created for previous versions of Internet Explorer and web standards”. Especially because of the fact that most companies are still sitting on back level browsers this is extremely important. And because this is so important Internet Explorer in particular lives up to the promise to provide a great deal of backwards compatibility by shipping with two rendering engines and compatibility modes. While probably still not the 100% solution to the compatibility questions it is a great relief for companies preparing for migration as this reliefs them from really touching applications and make real changes to the application assets (markup, styles and code)
      
   2. Forward Compatibility
      
      I would define forward compatibility as “The Support of evolution of the web by endorsing and supporting current and upcoming specifications and actively participate in the definition of those standards”. Now this one is a bit tricky as we all don’t own a crystal orb to look trough into the future. However alone by the statements and the involved actions one can get at least some ideas about how friction free and smooth future migrations will become. Supportive for a positive perception with respect to forward compatibility I would count active participating in the standardization bodies, recommending new standards, early adoption of not yet settled standards, providing guidance on usage of standards, etc.
      
   3. Artificial Compatibility
      
      Artificial compatibility or a compatibility that has been created and made popular as an benchmark thus creating a de-facto requirement of passing taking the benchmark in order to gain a positive perception. The problem with such an compatibility understanding is that they sometimes are not very helpful in or simply useless when taking the compatibility debate. One good example is the current ACID 3 test. There are many people out there thinking that the browser passing the test to 100% is the most standards compliant browser but this is not really the case as it only tests a subset of standards and it tests it upon the author’s interpretation of the specifications. And that there is much room for interpretation shows a simple example made by Ian Hickson, who is one of the editors of the HTML 5 specs at the W3C and maintainer of the Acid 3 test suite.
      
      “HTML 4 has an input element, which has a type="" attribute, which takes values like "text" and "checkbox." What should happen when you have an HTML input element with type="text" in a document is reasonably well defined: You display a text field.

      What should happen with input type="checkbox" is relatively well defined. However, with script, you can take the type="text" attribute, and change its value dynamically, while the user is editing the control, so that it is type="checkbox." This is not a common thing to do, and the HTML 4 and DOM2 HTML specs are completely silent on what should happen when this case is hit.

      The result is that different browsers do different things; IE will throw an exception, if I recall correctly, while Firefox will change the text field to a checkbox”
      
      There are other indications and statements that are quite a bit reserved to pay to much attention to those tests which I will spare here. For those interested just check out this or that. To sum it up I want to point out that I don’t say that tests such as Acid 3 are generally a bad thing but I think that just striving for the goal to pass a certain test and even optimize a product just to hit that target is a non goal and doesn’t help the web community in deciding which are the real important attributes are to solve the compatibility questions.

2. Some common misconceptions
   
   1. Micro-Benchmark results are the key criteria to make browser choice decisions
      
      Micro-Benchmarks are without a doubt very popular at the moment. Especially those measuring JavaScript performance like the V8 Benchmark, Sunspider, Dromaeo or Peacekeeper are extremely popular nowadays. The only problem with them is that they are measuring only one tiny aspect of the whole browsing experience and therefore may be not sufficient to make an impartial browser decision. An attitude by the way that I’m not alone with. Jim Rapoza, Chief Technology Analyst at eWeek for example said:

      “Face it, right now all browsers are more than fast enough. And if you're running into slow performance on the Web, you should probably check about 100 other things (ISP performance, site problems, etc.) before you start wondering about browser speed.
      So why is every single browser maker spending so much time and resources trying to gain the mantle of fastest Web browser? I think it's because performance is the only non-subjective criteria that they can hang their hat on”
      
      Don’t get me wrong, Micro-Benchmark are important and give a good insight about the current state of a browsers script or rendering engines especially with more and more applications making heavy use of JavaScript however they shouldn’t be the only criteria to base one’s browser decisions on. I mean even we at Microsoft now are riding this horse with the latest announcements about the rework of the JavaScript engine in Internet Explorer IE9 and the performance shown already in the current technology previews of IE9. But still there is the belief that there is a superset of of criteria that need to be taken into account when thinking about browsers and the usage of web applications.

   2. Specifications leave no room for interpretations
      
      I already gave an example about this further up in the compatibility section so here’s some more about that. A international standardization process is a complex beast. There are many parties involved (which is basically a good thing) but the more parties the more opinions and discussions. This is the reason that it takes a long time before standards are finally released and their specifications are complete and signed-off. So sometimes you need to rely and base your work (e.g. a browser) on unfinished specifications which may be unclear in certain aspects or may change over time. Think about CSS. There is still no final specification for CSS 2.1 available. And probably not only because of this Derek Featherstone, Group Lead Web Standards Project comes to the conclusion that:
      
      ”We don't even have a perfect implementation of CSS 2.1 yet”
      
      So its easy to say that one or the other browser is not implementing the specs correctly but with some insight it becomes obvious that there is not the one correct way and it is difficult for a browser provider to hit a moving target (unsettled specs).
      
   3. Browser migration is different from other application migrations
      
      To be honest I have no real clue about were this misconception comes from but I know it is all around. In many cases I hear or feel a lack of comprehension about browser migration and the related efforts to assess the applications if they are still working as designed. However I think this is something that is quite common in today’s IT environments. Think about migrations of JDK’s, Application Server upgrades or Windows Client upgrades not to speak of upgrade of a large SAP installation. Those don’t come without migration efforts either and they are huge in many cases. Of course IT responsible complain about those efforts as well but there still is an acceptance or an understanding that this is something that needs to be done. In the context of browser there is a total lack of such an acceptance and often this then leads to not migrating at all up to the time where there is no other chance anymore. However not only the efforts necessary will increase over time as I already pointed out but also those company will miss some great opportunity as we will see in the next section.
      
3. Application classification
   
   Let’s get a away from the philosophic and sometimes religious questions and get a bit more practical. If you plan a migration you are probably think about the right process or which are the right tasks. One important task within the process is to do some kind of application classification. As this also can give great insight into what the overall migration efforts actually will be it should happen very early in the process. Of course there are many different ways to classify applications and there may also be quite some company specific, internal classification factors. Nevertheless I will try to give a generic views on how to classify and estimate the efforts. Base for this classification is the source of the application or in other words the producer and how much it has been customized. As seen in the following figure the complexity and efforts of a migration increases with the customization level in combination with the sources moving from internal to external.
   
   
   
   Important to note is that this not only considers technical factors but also includes organizational and feasibility factors. For example an application from an external source may be harder to migrate because the VAR/VAP or ISV may not even exist anymore. This is especially important for application including binary components such as ActiveX controls. On the other hand if a web application is based on an ISV product that has not been customized the effort may be near to nothing because the ISV already has official support for current browsers.
   After doing this classification there is then the chance to prioritize which applications to migrate first and which can be eliminated completely. So a quadrant model for this prioritization could look like the one I depict in the following figure. 
   
   
   The most important take away from this in my opinion is that you shouldn’t look at browser migration in the context of cost only but also in the context of opportunity to create a comprehensive web application inventory which many enterprises still lack today, streamline the web application landscape and increase value and productivity through innovation by using new features and standards not available or supported with older browsers.
   
4. Migration Guidance & generic process
   
   So now I can get to the final guidance and outline a generic process for a browser migration. As it is quite generic and of course doesn’t touch any specifics of a certain vertical or even individual enterprise it looks quite simple but yet it is a good starting point to refine it and adapt it to the individual company.
   
   

A lot of text now simply to explain why I think that companies should

• treat the browser as a mission critical application
• define an independent strategy for it
• realize that its time to migrate to a current browser
• start migrating to Internet Explorer 8 today as it is probably still the best choice for enterprise IT-Environments because of its
  • Standards compliance
  • Compatibility features
  • Deployment options (IEAK, Slipstreaming, WSUS, AD, SCCM)
  • Group Policy customizability
  • Unique security features (protected mode, domain model, etc.)

So hopefully I created some awareness and the thoughts I tried to express about this, certainly very complex, topic was understandable, a bit helpful and created a sense of urgency to ACT NOW then I reached my goal for this post. And finally the answer to the question if enterprises need an independent browser strategy is definitely “YES”.

As always feel free to comment and start a discussion.