Merging content - a redesign dilemma

18 May 2009 - By Sean Fishlock

Having a content management system (CMS) is a great thing for enterprise scale websites with large numbers of editors working on them. It effectively separates content from presentation, allowing you to keep your content and apply changes to your design or structure.

But it does get a bit complex if you want to do both at the same time (which is what usually happens in large website redesign projects, particularly those using the Agile development model). Often this will involve setting up a second site (or "staging site") to develop and test while your current site is live and serving your customers. If you're changing the content and structure during this time, however, unless you've got editors updating both at the same time (which isn't always feasible) you'll inevitably end up with two websites that are out of synch.

It is a fairly new problem and consequently customers rarely consider the issues. Having had a bit of experience in it and currently working on such a project, I thought I'd share some of the trials and tribulations of the process.

While it is tricky to get both back in synch, it is possible.
There are a number of strategies to employ to get your fully redesigned website up and running. However it requires a lot of experience and very careful project co-ordination.

Preparing for the Merge and Putting on the "Freeze"

Taking a snapshot - at some point you'll want to takestock of your website at a particular point in time, to determine whatcontent is there and track any changes between the two sites. Onestrategy is to put a freeze on content editing altogether and adviseyour content editors to stop making changes, however on large andconstantly updated sites this is simply not realistic - especially whenmost redesign projects take many months.
Tracking changes - by logging changes you may be able tothe differences to merge them in future. Most database driven contentmanagement systems keep some sort of log which makes this easier.
Mapping pages - an Enterprise CMS could have a systemwhereby you can specify a secondary target address/URL for each page. This allows you to more easily map it to the destination in the newsite. It is also reduces the amount of double entry required whenmigrating from one site to another. However it can be a task in itself. Without it, at the very least, youshould be able to export a sitemap of both sites for reference and map it manually.

Bringing the content across

Database import - importing directly from one database toanother has its advantages, but also disadvantages such as mappingrecords to shared IDs. This is not always available though whenmigrating from one CMS platform to another different one as they canhave very different database schemas.
XML Import / Export - XML can be an excellent method ofexporting and importing to different sites using the same CMS or evendifferent CMS. This is especially the case when merging contentbetween different target locations. The main reason is that eventhought they aren't a "standard" format (ideally they should be) XMLwill typically identify the source and target locations for the content.

Both of these options allow for automated scripts which save a HEAP oftime. However if these options aren't available, then there is afallback/last resort.

Manual Import - when a poor CMS choice has been made inthe past, this is usually the punishment. For large websites, thismight involve copying and pasting large numbers of pages and a lot ofduplicate data. This might take many days, weeks or in rare cases - months. You may even ask yourself what is the point of havinga CMS if you can't readily migrate content between sites.

Planning your merge

Once you're ready, it should be a matter of running a script to bringthe content across to the new locations in the redesigned sitestructure. If new locations are ready and defined and proper mappinghas been set up in your existing site's CMS, then it should bestraightforward.

The key is to determine what to do with content when there areconflicts. Although it can be complicated, the easiest way is toaccept the page that was last updated. If there has been a freeze puton editing at some stage then you can be pretty sure that the morerecent updates were done on the "staging site".

The Aftermath

When all the dust is settled, with a competent project manager anddeveloper working on the job, you should have a working copy of yournew website with up-to-date content. However in 99% of cases, therewill still be a fair bit of clean-up to do. There are often small dataintegrity and content issues to deal with and the next step is to do afull review of the site. So keep an open mind and don't expect aperfect result ready to launch straight away. A large amount ofcontent brought across into the new structure is a good result.

Conclusion

Always plan ahead and let your developer know the full extent of yourplans for redesign. Never just assume that they will be able toaccommodate changes along the way, particularly if you start doingthings differently midway through a redesign project.

For smaller sites sometimes better (more cost-effective) to do thingsin stages, typically the new content structure first - implement itinto the existing site. Then do a redesign of the user interface. However this can be more involved and time intensive for your staff andalso place considerable demands on your web developer.

A good web developer with full knowledge of the CMS platform is essential.

Comments

There are no comments.