I was asked recently if I could very quickly write a content migration plan for a website onto gov.uk
This is what I came up with which is purely speculative in case I need to use it again:
Clarify what the deadline is – does all the content need to be live in one go or is the move being made over time
Create project plan
Arrange for TNA to archive the old website at an appropriate time
Take own back up of website
Create an internal comms plan
Create an external comms plan
Do content audit
- split between flat content and tools/transactions
- What do existing metrics show as most used content – it will help prioritise work – can any content be left behind?
- Content will need to be written so buy in needed from internal specialists and their time bid for
- GDS will probably want to redesign these which will involve user testing etc so plan this work early and carefully
- will probably need to reassess what the key user task are
Do a sample check of how long it takes to move or rewrite content – should help work out how long all the work will take
Sort out redirects
Content might need to be merged with existing content on gov.uk on the same topic (if it exists)
Keep users up-to-date with progress on the move so there are no surprises
Training needed on how to write for gov.uk
Training needed on the gov.uk CMS
Check redirects and monitor broken links
Do sampling to check that content can still be found by searching
Monitor feedback processes to make sure users are happy
I will add more points as they occur to me.
Here is a question to think about.
If you switched off your webserver now what services would stop working?
Well probably your website, but what else?
What about all those other bits and pieces that seemed a good idea to squirrel away because, well, we have a server.
So this is the other issue that troubled me when we rebuilt our website in March ‘what would stop working’?
Here is my list:
- SNAP surveys because we were not using a cloud based service – we moved our account onto SNAPs servers which involved talking out our survey team colleagues.
- Two private log in areas to transfer business information – not quite an intranet but fiddly to recreate in a new environment especially when there were a lot of different URLs in circulation.
- A private page for office use when the web might be our only communication channel with staff – being recreated in email alerting software.
- A custom built database of report recommendations – built in .NET and which does not work in our new environment – we are linking to a National Archives copy until it can be rebuilt.
- Other odd bits and pieces like our Contact form – we built a new one then had problems with emails from GSI addresses
- A toolkit built in flash that was not value for money to rebuild as it has been custom built – we put it on a .NET server, tidied it up and linked across to it.
I suspect this is only a small amount of issues compared to other organisations however dealing with these ‘legacy issues’ all added to the workload.
In the middle of March we launched a new version of our website in WordPress. The other key elements being that it is hosted on Amazon Web Services and the code is in Git. All fabulous stuff.
Though this was a major project, I tried not to make it a ‘major project’. However I did learn a few lessons so why not share some of them, painful blow by blow.
Ah, that fateful word in IT circles – legacy.
Things that are easily overlooked are:
- which bits of your infrastructure do you actually own – are they on your assets register?
- how do you (or someone else) decommission them and when?
- which contracts exist – when do they run out – how much notice do you need to give of non-renewal?
I will almost guarantee that your contracts have different lengths. How do you get them in synch so that any switch over can be co-ordinated? Will you have to pay extra money to extend a contract?
How do you avoid insulting your existing suppliers when you tell them that you have ‘found someone else’.
In particular what if you want an element of contingency if something goes wrong and you need to revert back to your existing suppliers? Or you need the old suppliers to work with the new ones? Tricky huh.
So relationship management skills come to the fore.
What is a website? Er, surely a site on the web?
I used the term ‘our website’ this morning when talking to a colleague and said that I might stop using the word ‘website’ and say our digital engagement platform. Or how about our communications platform; or our digital hub?
Weird huh? Well, maybe not? Certainly the word website says ‘what it does on the can’ but is it really accurate anymore? Does the word raise preconceptions in the reader of a static plaform of slow moving, slow changing content which is labouriously published?
If so, that is not want I want our colleagues to think of when I mention our ‘website’. How many of us have that kind of ‘website’ any longer?
Hence the search for a better word. So perhaps platform or hub is more accurate? I use this diagram internally saying that the website is the centre of our digital channels. Ironically as I inserted this diagram I realised that I have not even used the word website in the central circle.
The search for a word is on – your suggestions on a postcard please…
Drawing of digital channels