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
| Section |
Page views |
Pages |
| Planning |
36,377 |
Planning, Planning applications, Planning and building control, Search the planning application register |
| Job vacancies |
22,477 |
Jobs and careers, Schools vacancy bulletin |
| Housing |
14,359 |
Housing and homes, Southwark Homesearch, Properties to let |
| Libraries |
12,259 |
Southwark libraries, Library catalogue – renewals, requests, Library locations |
| Schools and Education |
11,234 |
Find a school, Education and learning, Schools in Southwark |
| Payments |
9,797 |
Payments, Debit or credit card over the internet |
| Contact |
9,413 |
Contacts, A-Z of services, Contact us |
| Rubbish and Recycling |
8,892 |
Recycling, Environment, Household refuse collections, Bulky collections |
| Events |
8,024 |
Events diary, What’s on, Discover Southwark, The Event |
| Council Tax and Benefits |
7,960 |
Council tax and benefits, Council tax |
|
= 140,792 |
|
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