Shelter’s great content migration

• Background
• Audit
• Stakeholders
• Workflow and system planning
• Communications
• Guidance and training
• Migrating the content
• Measurement
• Results
• Philip

Background

In 2019 the housing and homelessness charity Shelter planned to migrate its England and Scotland websites to a new content management system (CMS).

The old system was a dinosaur in CMS terms: Content and assets were all buried deep in an overgrown, obtuse tree directory. Finding anything was arduous. Publishing had become strictly the job of developers, who’d built so many add-ons and work-arounds into the system that it was laden with technical debt*: every publishing need, from new pages to basic edits, had to go through a busy dev team. (*A bantied-around term at the time.)

The new CMS was Contentful, a headless platform. It treats content as structured, easily findable and buildable blocks and components that an editor links together with other blocks or in pages. Very Lego. Content is separate from its presentation, so it can be reused in different ways. You can design workflows and governance into the CMS. Devs are liberated to work on the challenges they love. A brave new world.

But the change set up Shelter for a formidable migration. The old CMS had over 18,000 pages and assets.

Back to top

Discovery audit

Challenge #1: Getting to grips with all of Shelter’s web content for two countries. Understanding what we have, and its value to users and the business. With any migration, the first questions are always the fundamental ones. What content do we have? How good or bad is it? How old is it? Who visits it? How often? Who owns it?

I started with a list of these questions and others, and took the list to the project working group for their input and to get agreement on audit criteria.

I then took nearly a month to assess:

• quantitative metrics: volume of content, totals by content types, content IDs, traffic stats, clickstreams, downloads, and content timeliness
• qualitative measures: usability, accessibility, accuracy, best practices followed, strategic alignment, brand alignment, audiences

I built the mother of all spreadsheets, with column filters for each criteria. The spreadsheet became the source of truth for the editors who did the manual migration and the devs who did the auto-migration.

Challenge #2: How do I stay on top of changes to the website? A moving target is problematic. For this, I relied on all ‘requesters’ (content owners who’ve asked the dev team to publish or edit) to capture each change in the spreadsheet. And as a failsafe, once a week I asked the dev team to flag any pages they’d added or removed.

Back to top

Stakeholders

Challenge: How to get all stakeholders aligned with the project?

Fortunately, Contentful and the migration were part of a large org-wide transformation programme in which Shelter had invested heavily. So appreciation for the project was in place. But the pressure was still on.

I involved stakeholders in two waves. First was the working group. I invited the primary content-publishing teams: housing advice, support services, campaigns, policy, income generation (fundraising), retail (shops), brand, central marketing, and professionals. I also invited IT.

But I wanted to form a working group with a reasonable size. Anything over 15 becomes unwieldy. So I invited people who could represent 2 or more like-minded teams, such as campaigns and policy, and housing advice and support services. Plus the leads for product and content teams. Our core group came in at 12 people.

The second wave was the next circle of impacted teams as well as business owners and leaders – especially the project sponsor.

I had 2 key meetings with each stakeholder – one in the first weeks, an interview to familiarise them with the project and learn about their team’s work and its impact on the project. I took them through the project roadmap and deliverables, and I asked them:

• What are their expectations for the project?
• What are their (or their team’s) plans and priorities over the next year?
• What are their internal comms preferences? How do they like to be kept up to date, and at what level of detail?

Everything gathered from the interviews I poured into my stakeholder map, a spreadsheet I used regularly for planning comms, understanding where to engage on a project facet, and anticipating pushback.

For stakeholders not in the working group, I gave them a range of options for staying plugged in beyond regular email updates. For a handful, I had face-to-face catch-ups during the months of the project.

The second meeting was after I’d completed the content audit, to take them through the results and get their input on the big question of what to keep, what to change and what to remove. While these discussions were sometimes difficult, stakeholders appreciated having clarity on their content and an understanding of its value.

The main goal in these chats was to remove and archive as much low-visit, older pages as possible. We also looked for places where multiple pages could be combined into one.

Through this process, we reduced the page total for both countries to roughly 7,500.

Barriers along the roadmap

Thanks to the outreach and cascades from our working group to their teams, no stakeholder was caught off guard by our plans. But twice it was the project team who was caught off guard, by sudden requests from the campaigns team to launch new petition drives.

Shelter is a campaigning charity at its core. Its official name is Shelter, National Campaign for Homeless People Limited. Its lobbying of the government and local authorities for better policies and laws regarding homelessness and renting have made big impacts.

So when the campaigns team says it wants to launch a campaign, everyone jumps. And while the team is able to plan much of its work – such as for calendar events like annual party conferences – the bulk of its campaigns are reactive in nature. Their work following the Grenfell fire focused anger on authorities, galvanised support for victims, and inspired demand for change.

Five months into the migration project, we were set to go live with our first pages on Contentful – the Professionals section. That week, the campaigns team announced a new campaign, to stop discrimination by renting agencies against people on benefits.

The issue for us was resources. Our CMS launch required an all-hands-on-deck approach by our dev, IT and product teams. The campaign would require new multi-channel content, petition design including data flow, a real-time counter of petition signings, and all the necessary testing.

I negotiated with the head of campaigns. Their hope had been to capitalise on recent press coverage of discrimination by a large national letting agent. In a meeting with the head and others, we realised the story would stay active for a few weeks and that we could use social channels to build awareness and public anger. We agreed to delay the digital work on the campaign by two weeks.

Two months later, just as we were about to launch another section, the campaigns team had another unplanned request, to launch a new report on social housing. This was caused by a gap in communications. As much as I’d tried to keep a full view of teams’ plans and keep them aware of ours, a policy manager had worked on the report out of our sight.

This time, time flexibility wasn’t an option. Government policy makers were anticipating the report. So we agreed to bring in a freelance content design and developer. The report was launched successfully and we were able to stick to our roadmap.

Back to top

Workflow and system planning

Building a content model

Challenge: How do we give users of our luscious new CMS the ability to create great content for their audiences? To use the handy metaphor, which Lego blocks should we build into the system to give authors a range of valuable and relevant choices? That’s the goal of creating a content model.

There are 2 driving yet competing forces in creating a content model:

• Giving content authors flexible and relevant options when they plan their content
• Protecting users and Shelter through enforced standards

Modelling content comes down to a dance between these 2 aims. Should we give a team the ability to create a table if it’s likely to make for bad UX? Do they need a jump menu component if they’re not publishing long form pages? What colour options do they need for buttons? Should we let them embed videos if they’re not commissioning them through our filmmaker?

One more driving question: How can we ensure consistency, in UX and in brand?

And a rather large curve ball: In 2019-2020, Shelter rebranded. From a UX perspective, the timing was fortuitous, as the new brand dictated a new look and feel for content just as our developers were building the components.

I worked closely with the UX lead on this. We focused on content purpose, and broke it into 4 categories:

• Informational – meeting user needs and answering their questions
• Navigational – helping users find what they’re looking for
• Promotional – extending user journeys through related content or through business-led content like events or campaigns
• Conversion led – helping users complete a task

With these in hand, we met with a mix of business owners and content owners. Using their existing content and pages as a starting point, together we explored how to improve the user experience through new or amended content types.

Out of those conversations, we built a list components and assemblies that meet all the needs of teams, users and Shelter. I created a content model matrix: a table listing each component with all its elements: headings, graphics, images, colours, etc. The UX lead then created a component gallery in Figma: visuals that included specs, rules and constraints. (Note: this became Shelter’s pattern library, with a design system later created in Storybook.)

Between the matrix and the Figma gallery, the developers had what they needed to build designs into the CMS, as content creation forms the authors would use.

Workflows: roles and permissions

Challenge: How do we design efficient, effective publishing processes, at both the human and the system level?

A key aim of the CMS project was shifting Shelter to devolved publishing – giving content-owning teams the keys to the car – a change the central digital team supported cautiously but devolved teams relished.

The work included:
1. A workshop including publishing teams to design a simple publishing human workflow.

2. A separate workshop, limited to the digital team, to decide a handful of CMS user roles and their powers, and mapping those to each team.

One challenge of the devolved publishing model: Limiting the publishing powers of some teams, for several reasons:

• To control content quality and user experience
• To protect brand standards
• To manage risk to the CMS and its tech infrastructure

By the same token, we didn’t want to discourage teams from embracing Contentful and its potential for helping them communicate to their audiences in new ways.

So we also decided to create an author transition scheme – a way for devolved teams to earn greater publishing responsibilities over time.

3. Designing a system workflow to support the human version. After a short discovery, our product team chose to integrate Contentful with Jira. The idea was that specific CMS actions would trigger corresponding Jira actions and email alerts:

• When a draft page is created by an author, a ticket is created in Jira and the assigned reviewers get an alert with a link
• If the reviewer leaves comments, the author is alerted
• When the page or content is approved and ready to go live, a super-reviewer with publishing powers is alerted
• and so on

Several thorough proof-of-concepts workshops were run by a product manager, writing user stories, mapping CMS roles to teams, and diagramming an MVP process to test and validate. But to date, this part of the puzzle hasn’t been solved. The dev team is still investigating the technical solution.

Back to top

Communications

The challenge: Keeping the stakeholder audience and wider Shelter staff informed, engaged and interested in the CMS project.

I believe in the power of project communications – within and between teams, with affected users, business owners, leaders, and partners. But I realise Steve in Finance isn’t going to drop what he’s doing to read my detailed update on CMS search tools. But maybe Steve can give it 27 seconds to read the headlines.

So I like to establish a 2-tiered message hierarchy*: the quick highlights and the juicy detail (but without ever using the word ‘leveraging’).

I wrote a comms plan, as much to reassure the working group and sponsor that project news would stay percolated as to help guide me.

The plan outputs:

• A twice-monthly somewhat templated email, highlighting what’s been recently completed and what’s next in the backlog.
• A page on the Shelter intranet, clearly signposted on its homepage, featuring basic info about the project, FAQs, a glossary of project terms and acronyms, abbreviated updates (summarised from the emails)
• A bank of elevator speeches – an idea I had after reading something (a blog I think) about snack-sized project comms. I wrote a handful of short texts covering what the project was, why Shelter needed it, how Contentful would transform our digital communications, and how the organisation was devolving publishing. I put these on the intranet as a single download, and also on Sharepoint – with links to put those locations in each email. (While the internal comms team couldn’t give me download stats, a few people told me they liked the elevator speeches and found them valuable.)
• Short in-person updates at every logical opportunity: in project meetings, as a guest as other teams’ meetings, in 1-to-1s with stakeholders, over pints with strangers (okay, not that one)

* In Giles Turnbull’s excellent book The Agile Comms Handbook, he suggests a 3-tiered hierarchy, so I feel validated in my tiers. And in hindsight, I wish I’d started and sustained a project blog, for the Shelter world to follow along – a central idea in Giles’ book.

Back to top

Guidance and training

Challenge #1: Because of Shelter’s move to devolved publishing, I not only needed to teach staff how to use the new CMS, I needed to teach many of them to be web authors. They had to learn Contentful and best practices in the bargain.

I wrote guides for every facet of Contentful: the basics like creating, deleting and finding content; how the systems connects content together; all the component and assemblies (components lego-d together into bigger blocks); and tools for building hierarchies, redirections, making short URLs and more. (For a handful of teams I made video tutorials.)

Then I wrote a guide to writing online content and had our search marketing officer write a guide to SEO, and worked with the content design team to update the house style.

As for training, I ran 2 to 4 hour sessions for each publishing team, taking them through the parts of Contentful they had access to. Everyone got to try each component their team had as options. It was gratifying to see them get enthused about the possibilities.

I loaded trainees with links to the guides and to further content wisdom on sites like NNG’s. I gave each team their own sandbox – an environment (or ‘space’ in Contentful lingo) for them to practice their skills, with some exercises to try. And I encouraged them to contact me with questions and comments.

Challenge #2: Once you’ve trained someone, how do you keep them committed to content quality? I applied a two-pronged solution:

• With their input, we agreed a set of metrics to capture monthly, and I asked the digital analysis team to set up reports in Google Analytics, and use them in a running dashboard of content performance.
  
  
• In the months after migration, the content team formed a content community of practice – a hierarchy-free group of digital practioners who meet regularly to share ideas and foibles, support each other, and suggest changes. And crucially, the CoPs were given ownership of standards and best practices. By owning them, they’ve embraced them.

Back to top

Making the move

Challenge: How to migrate over 7,500 web pages from 2 country’s websites to a new CMS, efficiently and with as few errors as possible.

The first decision was identifying which pages to move manually and which to automate. It was a straightforward choice: Our criteria for auto-migration was high-volume, heavily templated pages: Press releases and policy report pages mostly.

Manually – I added editorial workflow columns to the mother of all spreadsheets, and entrusted it to a rota of content designers and freelancers (who were first test users of the new guidance). They moved sections one at a time, following the project roadmap sequence and using ‘content freeze’ periods. Each section was moved smoothly.

To enable the websites to sit on 2 CMSs simultaneously, the developers built an ingenious solution: a toggle tool that allowed us to direct any URL to either platform.

Automated – This proved quite a challenge for the dev team. The solution was a 2-step process using a clever script:

1. Extract content from the old CMS, structuring its HTML into a spreadsheet containing like-for-like elements (old code mapped to new, basically)
2. Insert and validate content in Contentful

It took four months before the developers were able to get the script working effectively.

Back to top

Measurement

Challenge: What are the meaningful metrics that tell you how a content migration has performed? Beyond that, which measurements tell you how a new CMS is performing? Or how well a cultural change like devolved publishing has succeeded?

Focusing on the migration, the only real KPIs I worked towards were hitting our launch dates and having a 100% success rate on content performance in Contentful. The manual migration was delivered exactly as hoped for. The content designers stuck to ‘2 pairs of eyes’ as their review principle, and the occasional broken link or typo was caught on the staging site before going live. Each section was built and launched, some with new components, and the teams owning those sections were happy.

With the auto-migration, once the devs figured out the code requirements, a grand total of 4 pages failed after go-live: 2 pages each in England and Scotland. They were identical pages, both policy reports that we simply rebuilt manually. (I’m still not sure what failed.)

The biggest metric for Shelter and its users was speed. We all had a 2 second target for average page load. The agency and our developers designed an architecture around Contentful that used a static site generator called Gatsby, which compresses a page’s code thus greatly reducing its weight. It also helped that Contentful’s job is essentially to be a content repository – a warehouse of stuff all linked together, and it relies on links (‘webhooks’) to APIs to perform the range of services a modern website requires, rather than have those services built into an already-laden CMS.

Back to top

Results

The Contentful project has lifted Shelter out of the digital dark ages. It’s given web communications to the people doing the communicating: the teams delivering the charities services and products to the audiences they’re close to.

The greatest fears of the central digital team about devolving content publishing – that it would become a wild west of unusable, off-standard content – haven’t come to pass. If anything, the Contentful project formed connections between teams via the business asset that touches the majority of an organisation: content. The conversations and collaborations that grew out of the system, like the content community of practice, led to a heightened focus on getting value from the full life of content.

That mindset evolved into a full-fledged function within Shelter. The concepts of content lifecycles and content governance (which I helped develop) were embedded and matured into a full commitment in the form of the new role of Content Operations Manager.

Back to top

Craig played a vital role in helping Shelter migrate its website to a new CMS and publishing system. He became our expert on the Contentful CMS, built a content model that met the needs of internal teams and external audiences, and created invaluable internal documentation to help people get the most out of the new set up.

The work Craig did was impressive enough, but what makes him such a pleasure to work with was how he did it. Despite the scale and complexity of the migration, Craig remained good humoured and patient, and was always willing to hear the other point of view. The trust and engagement he achieved with this approach played a big part in the success of the project.

Philip Wilson, Product Lead, Shelter

---

Read about my adventures in content advocacy or about my work on Shelter’s digital framework.

Back to top