Alice Ainsworth

Migrating the content of a council website can be a pretty intimidating task. The typical local government site will have thousands of pages, pdf downloads and images. Depending on the way you work you might also have a couple of hundred content owners/authors to think about.

Having recently gone through the migration process at Southwark Council I thought I’d share how we went about it and what we learnt along the way – what worked well and what we would do differently.

To give you an idea of timeframes, we first started planning for content migration in August 2009, carried out the migration in January 2010, did quality checks and rewrites throughout February and then launched the new site at the end of March 2010.

Step 1: Know where you stand

August 2009: The first thing we did was ask our CMS support company to provide us with a spreadsheet listing all the content on the site. We wanted to know:

• Folder structure – how many levels deep did the content go? Where was the bulk of the content located and how many pages were there in total?
• Creation dates and review dates – how long had pages been in existence and when were they last updated?
• Content owners – how many gaps were there in content ownership? How many authors did we have, how many pages did they own and when did they last log in to the CMS?

The findings of this review were that we had:

• 2,630 live pages  - of which 1,489 had not been reviewed in the past six months. Aargh!
• 1,389 unpublished or archived pages
• More than 300 CMS author accounts but only about 50 ‘active’ authors

Step 2: Cut the crap

My advice – before you even think about migrating anything you should delete everything you can.

Start by looking at your stats

We had implemented Google Analytics on the site about a year previously so we had enough data to see what information was popular, what search terms were used – and just as importantly – what pages nobody was looking at.

Patterns among council sites don’t differ much. On an average month just 30 pages accounted for almost half of all page views on the site (not counting the homepage and search).

July 2009

Set some basic criteria for content culling

• How many visits does the page have to get to make it worthwhile? If it hasn’t been viewed more than ten times in a month is it really necessary?
• When was it last updated? Does the page have an owner? Can you verify that the information is up to date and correct?
• Is there a statutory need for the information to be online?
• Give it a sanity check. Is anyone still interested in the results of a 2005 football tournament?  Has the event/consultation you’re advertising been and gone?

So, between August and December:

• We cut the number of live pages by 20%
• We filed the remaining archived and unpublished pages into a ‘do not migrate folder’ – just in case it turned out there was anything worth keeping (there wasn’t).
• We worked with authors on priority areas of the site to make sure that they were reviewed before migration. By priority I mean pages with a high volume of traffic or that contained essential information e.g. child protection
• All authors were given notice that a content freeze was going to be put in place in January and were asked to check their content beforehand. A few last minute training sessions were provided in order to make sure everyone was able to update their information.

Step 3: Plan your information architecture

If you’re moving all your content from one CMS to another it is the perfect opportunity to review the structure of your pages and do some thorough user research.

We were working on the move to a new content management system and new design but there was no way in the world we wanted to keep the same information architecture.

We had previously had five headings: Your Council, Your Community, Your Services, Discover Southwark. Unsurprisingly enough 75% of content was found under the heading of ‘Your Services’.

We’re lucky within local government to have the local government navigation list. Don’t get me wrong, I think it has a lot of flaws but it gives a great starting point. I’d used the LGNL at Winchester City Council so already knew it pretty well, and was aware of some of the issues around its ‘poly-hierarchical’ and all-embracing (kitchen sink included) nature.

I don’t believe anyone else should dictate your IA – it needs to be tailored to your local community, focusing on local priorities and using the language of your residents not central government.

So, we used the LGNL as our basis, stripped it down, moved things around and compared about 100 other council sites to see if there was anything we wanted to copy. For example, through our knowledge of Southwark it was decided that regeneration deserved to be a top level category, rather than be tucked in under planning.

Step 4: Getting to the actual migration process

Migration can be slow and boring and there will always be a temptation to outsource. My personal choice would be to avoid this.

Migration does not equal copy and paste

Don’t listen to anyone who tells you migration is just copy and pasting or that they can ‘write a script for it’. If that is all you are doing you are wasting a brilliant opportunity.

Give a small team of e-comms professionals a style guide and the remit to delete and re-write bad content they will work wonders with your website, ensuring that pages are jargon-free, up to date and that they cross link to other relevant pages within the site. You just can’t get that from a robot.

If you can use people who actually already know a bit about your council they will also pick up all kinds of potentially embarrassing things lurking in the deepest darkest depths of your site…

Start small and simple

Take your migration plan and test it out on a small section of the site. Choose a section that doesn’t require very regular updates e.g. the business section and check that everything goes as expected. It probably won’t so it is useful to know what the problems might be as soon as possible. And by migrating the more static content first you run less risk of having to duplicate the work down the line.

Verify as you go along

If you can, get authors to check their content once it has been moved over to the new CMS and it has gone through your initial quality checks.

If you have time you might also ask managers, then portfolio holders, then all staff to look for problems. Some of these will be quick fixes and some will be more fundamental problems but if you know what all the issues are you then have the choice about whether to fix them prior to launch.

The more internal buy-in you can get during this phase the easier your life will be post launch.

Step 5: And finally

• You can’t put lipstick on a pig! Allow enough time for internal quality checks of the content before going live. No one will care about a new design etc if the content is rubbish.
• Make sure you have easy access to your old site for at least a few months after you launch. No matter how rigorous you are, sometimes things get missed.
• It doesn’t have to be perfect. It probably never will be, but you do need to make sure that the top pages, and the key tasks are tested sufficiently prior to launch.
• Ensure you have enough people power post-launch to fix problems quickly.
• Get authors re-trained as quickly as possible

The local gov day at Google’s London HQ this week (#googlelocalgov) definitely gave me some food for thought. No, they didn’t have all the answers, but as a group we do tend to have a LOT of questions.

There are a few things I’ll be looking into over the next few weeks as a result:

1. Google Adwords - I want to see just how much bang a council can get for its £300 buck in adwords. The Hillingdon example (pdf) was very interesting.

2. Site Links – The links that appear under Southwark Council when you do a google search are probably already the most appropriate but I’m not sure the landing pages they take you to are totally up to scratch…

3. Being more garish and less subtle – if it really only takes eight seconds for someone to decide if they’re going to click through to anything else from a page we need to make things REALLY obvious. What are the pages we really want people to see? We need to make the links more prominent!

4. Make registration easy and useful – when we move to a CMS that allows registration we need to make it SIMPLE, show the benefits, be reassuring and transparent and avoid distractions. Test test test to make sure we’re not losing people at the same stage every time and make sure we get them to the finish line. Sounds obvious but it will take a fair bit of work to get it right.

5. Advertising on a council site – This isn’t a high priority and I’m not sure how well it would go down but it might be a consideration when looking at template design – particularly for the what’s on section of the site. I was quite impressed by some aspects of Nottingham Council’s what’s on section.

6. YouTube – I didn’t know that YouTube was the second most popular search after google. At Southwark we have a channel and a few videos on it but nothing particularly new or exciting. But I think this will take off soon. A couple of good examples were shown on the day:

I really like the way annotations have been used in this video:

I thought the Visit Blackpool video was original and entertaining:

Both of these examples relate well to the kind of campaigns that we’re running at Southwark Council…

7. Google maps – There doesn’t seem to be a ready answer about how councils should be using Google and Ordnance Survey maps so it makes it even more important that we work together. Residents don’t care what goes on behind the scenes – what they care about is being able to find local services. They’re not interested in the boundaries of a borough when they’re looking for their local park or nearest recycling centre.

There were plenty more subjects being discussed on the day but these are the key points I took away from the day.

Go to the Google local government resource centre for more info.