Great Ormond Street Hospital (GOSH) is one of the most prestigious international centres of excellence in child healthcare and a much-loved charity in the UK.
Tom Saunders, Product Director, Torchbox talks to Seth Freach, GOSH Charity’s Head of Digital Development, who shares their full website migration story and learnings.
Taking a step back
When the Drupal 7/8 end of life schedules were announced we knew that we had some big decisions to face.
Having personally worked with Drupal for a decade and a half, I know the platform, the ancillary companies, and the developer community well. Our Charity and Hospital websites have been running on Drupal for many years. Staying on Drupal would have felt like a safe choice for everyone.
But we decided to take a step back and take in a broader view of the CMS market. Both the team and leadership wanted to step out of that comfort zone and invest time and research into other options.
Doing so was the right decision and I would encourage other organisations to do the same.
Picking a new CMS and delivery partner
We took an RFP approach to both the tech solution and delivery partner. After some internal work to articulate our wants and needs, we asked an array of vendors and agencies to have a look at our broad requirements, recommend a technical solution, and explain why they would be best positioned to deliver it.
After a few rounds of discussions, we found ourselves seriously evaluating Wagtail, Drupal 9, and a proprietary front end build on top of Contentful.
Saying goodbye to Drupal
Our Drupal 7 sites ran on a lot of custom module work and an upgrade path to Drupal 9 would essentially be a replatform itself.
With that in mind we took a step back to assess where our CMS needs were, Drupal’s alignment to that, and a wider view of the market as well. One thing that became clear was that the Drupal ecosystem was doing fantastic work pushing into the DXP [digital experience platform] space and were on a trajectory to continue the journey. That suite of products and solutions, however, wasn’t a direction that aligned with our CMS needs. It felt like a big decision, both technically and culturally, but once we looked at it through the lens of “best fit for the Charity’s requirements”, the team was fully on board and excited to embark on a new direction.
Why we love Wagtail
Wagtail’s editor experience was a key driver for us. One of our goals with the project was to enable more teams across the organisation to have more control over their content and stories. For that we needed a powerful and flexible CMS that also had an editor experience which was intuitive and uncomplicated. Wagtail provides a great editor experience!
Another consideration was integration with Salesforce. Torchbox demonstrated to us early how Wagtail could be leveraged to handle the data we needed to have in the CRM.
Also, under the hood, shifting from a PHP application to one built with Python was a deliberate and strategic choice.
Integrating with Salesforce
Salesforce plays a big part in our daily work. We depend on it to know the full picture of activity and how we are able to best steward our supporters, amongst many other things. One of the objectives that we set for a new site was to replace three legacy systems that were part of our workflows with data that we need in Salesforce. With each of these built on different application platforms with different vendors, it was becoming a challenge to scale much further.
Wagtail replaces these systems with automated integrations and has given us much more flexibility to look forward and build from. And we have more timely information available to us to better drive our mission.
The (often dreaded) automated content migration!
Content migrations are often messy affairs, so this was one of my biggest concerns from the beginning of the project. A lot of our historic Drupal content was WYSIWYG heavy, as well. So, we knew going in that there would be a lot of exporting, HTML parsing, and trial and error.
Drupal and Wagtail work with files and media differently, which was another aspect that had to be factored into the automation process. By talking about and working on the data migration early in the project, we made sure that we built feedback loops around the shape of content, assumptions, and expectations on both the source and destination systems. We ran migration tests iteratively and alongside of page type development. As we approached launch days for the sites, the final migrations that were run went as planned and without any downtime for editors because we had seen it before, many times.
It was probably the smoothest content migration I’ve ever experienced.
Working effectively, remotely
Development on the project began right as the COVID-19 pandemic was changing all of our lives; lockdowns, home schooling, working patterns, etc. were all forming into what would come to be called “the new normal”. There were a lot of questions all-around about how well a project like this could be designed, developed, and delivered with everyone working remotely. In the end, it worked out wonderfully. We learned to use (and to not overuse) new tools, and the project and work culture shifted where needed without losing sight of the end goals. I think everyone involved on both sides quickly settled into the groove of the project and the remote working aspect wasn’t an issue at all.
The real life impact
– 40% reduction in hosting costs
– Huge improvements for accessibility
– A simpler editor experience for distributed content teams
– A more scalable technical architecture that relies on fewer moving parts
– No disruptions, down time or content freezes
