Throwing out the bathwater

I was once a contractor involved in a web CMS platform migration where the client had a large investment in their existing website in terms of the content, layout, design, functionality and so on. Their content management system resulted in very fragmented storage of content across multiple silos, and required frequent interventions from the original developers, and in house IT staff, which was both costly and time consuming. All in all, a bit of a disaster in terms of architecture, resulting support costs, and the sheer time and effort required to make even minor content changes, let alone adding new application functionality. The website was a huge source of new customers, and sales, and therefore a critical piece of this medium-large enterprise.
If this sounds like a worst case scenario, you haven't seen inside too many businesses websites. This is not only a common situation, it's practically the norm.

What I hope to show is that the predominant way of thinking when fixing such a system is usually wrong.

The most common approach I see amongst stakeholders and technical staff when designing a roadmap to a better website is an approach based on a foundation of crippling caution and a sickening fear of disaster. To make matters worse, many staff involved in the implementation will decide that the project is doomed before it has started, and therefore start immediately to minimise their personal culpability, ready for when the proverbial hits the fan. But I digress.

The existing investment in the web site is often something that weighs to heavily on the business. Its the conclusion that "because we've invested $x million in this website, we cannot simply throw it away".

Lets take a closer look at that assumption.

1. What have you really invested in? When you look at where that investment has gone, it will be a combination of things like, hardware, licenses, staff salaries, third parties, web design, software development, testing, project management etc. Only the intellectual property that you have created is an asset of the business, the rest is an expense. You may have spent $5 million over 10 years, but your intellectual property asset, the value of the content created, is completely unrelated to that expense. It may be more or less valuable, depending on how well that content is able to drive revenue and profit. 
2. If what you have created is intellectual property, where is the intellectual property? What form does it take & what does it look like? I think the commonly held view is that a web page, like a document, is a self contained piece of intellectual property. The way the page looks an feels is assumed to be integrated with the content into a whole, but this is misleading. Content and presentation can easily be separated (this has been the point of HTML and CSS since the 1990's). Yes there is intellectual property in the appearance of the content, no doubt. But the larger the web site, then less of the asset is tied up in the cosmetic appearance of the content, and the more that is pure content.

Where am I going with this? I want to point out that when you have a large web site, chances are that the cosmetic appearance of the content is of very little value relative to the value of the content itself. Going back to our migration roadmap, the approach put forward by the business is usually to "migrate the content to a shiny new WCMS platform whilst keeping everything looking exactly the same". This is considered the safest approach ("hey we can just paste the HTML across"), but is in fact a very bad idea. Why? Well, for a start you are keeping the dirty bathwater in order to keep the baby, when the two are easily separable. Separate your content from its presentation. Secondly, you are never going to get a better opportunity to implement a substantial overhaul of the look and feel. Thirdly, you have probably grown very comfortable with your old site design, but chances are its not that great to someone with fresh eyes. And forth, your HTML and CSS is likely to have grown fat and bloated over the years as various people have had a go at altering it over the years, each looking at only one part, each with a different idea in mind.

The problem with keeping the old HTML and CSS is that you are actually making work for yourself, not saving work or reducing risk. Importing bloated, bad HTML and CSS into a new WCMS is going to take longer and cause more pain in the long run than writing clean HTML and CSS from scratch. This is because all that bloated code is going to take many hours for web developers to understand, and is going to cause inconsistencies across the site, and major headaches in testing.

The outcome of a major website migration is more likely to be successful when the business seizes the opportunity at hand, keeps the content, but re-designs the look and feel. Don't keep the bathwater to save the baby!