How does a small but nationally visible non-profit organisation go about moving their news-focused website to a different content management system? A good friend of mine works for a non-profit news organisation and asked me this question recently, so I put together some very brief notes based on some of the website migrations I have done over the last few years for similar organisations (a charity, an industry trade body, and a specialist news publisher).

The client being a small non-profit organisation constrains the solution to license-free (non-commercial) content management system (CMS), because at an industry standard of around $20k and upwards, the license costs for commercial CMS products tend to be out of the range of small non-profit budgets.

There are therefore five key things to consider for migrating an existing news-focused website for a non-profit organisation to a new CMS:

1. What open-source technology should you use?
2. To what extent should you customise the technology and how?
3. What is a reasonable cost – one-off and ongoing support?
4. Who should undertake the implementation?
5. Where should the site be hosted?

There are plenty of other problems to solve once the initial decisions have been taken, but for a simple, news-focused website, with content only in English, we don’t need to worry about managing translations or dealing with transactional workflows. So what’s next?

The website in question publishes about 50 news stories every week (2500 articles per year), and has an archive of around 10 years’ material, so say 20,000 articles in total. On average each article might have two images to go with it, so let’s say we also have 40,000 images. This is a fairly modest amount of content, although large enough to require an automated import of content from the existing system and minimal manual intervention.

The organisation had done its homework, and had already identified Drupal as a good technology fit:

We’d like to use an off-the-shelf [CMS] solution. Everything we’ve read suggests that this will require a fair amount of customisation, but the less the better. The Economist website gives a fair idea of the kind of thing we’re after. It’s done in Drupal with quite a lot of customisation.

A useful first question should be: “do we actually need a CMS?” This is a serious point: you might actually be better off storing HTML fragments in version control and serving this static content on-demand – I know of at least one major UK consumer price comparison site which has ditched its CMS technology and replaced it with text files in Subversion, because every CMS technology they tried hugely constrained their  web application architecture and operation.

1. What open-source technology should you use?

Assuming you’re willing to live with the constraints of a CMS, Drupal is a good choice. You should also look at Umbraco and Magnolia. Drupal and Umbraco in particular are well-supported and have plenty of people skilled up. WordPress is also a worthy contender these days, and is pretty powerful; several news-focused websites such as TechWeekEurope use WordPress to good effect.

2. To what extent should you customise the technology and how?

Building on an open-source CMS with your customisations can work. However, consider whether you can achieve what you need with something ‘hosted’ (aka SaaS) like WordPress, because although features may be limited, that can be a good thing. The headaches of security patching go away when you use a hosted service, as do those relating to the “truck factor” of being dependent on one tech guru.

3. What is a reasonable cost – one-off and ongoing support?

‘It depends’. You need to factor in the ongoing maintenance and support here. That ultimately is the determinant of how cost-effective was the initial outlay. However, the stages and ‘bare minimum’ effort are broadly as follows:

1. Determine end-to-end requirements including hosting, failover, editor user experience, high-level feature set, etc. – probably 2-3 days’ work.
2. Initial default install of Content Management System (CMS) plus initial user setup and security hardening – 1 day
3. Content migration from old system into new system – probably 1-4 days, depending on how the data is currently stored.
4. Re-working content to hyperlink correctly, etc. – 1-2 days
5. New template design (probably by an agency or designer) – 2-3 days
6. Testing workflow, permissions, backup/restore, and other operational issues. – 1-2 days
7. >>> Initial launch with no customisation <<< consider stopping here
8. Review requirements for customisation of CMS functionality. – 1-2 days
9. Implementation of customisations – N days (5-10)
10. Safeguarding for customisations: version control, backups, additional developers, etc. – M days (2-4)

So, an inside minimum of 8 days to do this right with a customisable CMS. At a day rate of $200 per day, that’s obviously about $1600. With more complex data/templates/etc. you might need 2x or 3x that. Budgeting for around 20 days’ work seems reasonable.

4. Who should undertake the implementation?

The most important aspect of choosing the supplier to do the work is to find an organisation which will offer ongoing support and maintenance after the initial migration is complete. Avoid at all costs suppliers who are interested only in the initial implementation work and not the ‘after care’ needed to ensure that the website does not decay after the initial launch. You will not be able to (or want to) do all the maintenance yourself, nor should you.

5. Where should the site be hosted?

If you choose the ‘hosted’/SaaS model, then hosting is taken care of for you, and this is a *major* win. If you believe that you should run your own instance of a CMS, then you’ll need to do some rough calculations on expected bandwidth costs and ensure that any limits on the database size are high enough for (say) 2-3 years’ worth of operation. You probably want separate database and web servers to spread the load, but a load-balanced web layer might be too pricey. Perhaps you could run Squid or Nginx in front of the web server itself to offload much of the content delivery, leaving the database and web application on the same machine.

Summary

Migrating a news-focused website to a new CMS is not particularly tricky, but there are some longer-term issues to consider. Above all, you want to keep you operational overheads low, which means off-the-shelf where at all possible. Don’t forget that pretty much anything is *possible* to achieve with a web CMS and some custom code, but is the ongoing effort of maintaining that customisation really worth it? Could you make do with something slightly less bespoke, in the knowledge that security holes are patched?