Website migration at scale: Lessons from the move to EdWeb 2
In the run-up to launching our new undergraduate and postgraduate degree finder service throughout 2025, we also had to contend with a migration to a new corporate content management system (CMS) in late 2024. While this additional task was challenging, I learned a lot from my role coordinating the move with both central and devolved teams, building on existing relationships and gaining useful insights I can apply to our transformation projects this year.
Wait – what’s a website migration?
At its most basic, a website migration is moving all the content, functionality and design from one ‘platform’ to another. This might be due to technology going out of date, wider institutional web strategy, or because people want to update the underlying technology in order to support new functionality and release new features.
Project planning: how we ended up with a project coordination role
All of the above applied to EdWeb 1, which hosted our main subsite (Studying) and its ‘child’ sites, such as Undergraduate, Postgraduate, and so on. However, while Prospective Student Web is responsible for a lot of the content, we don’t manage all of it day-to-day, instead devolving things to subsite owners (like Online Learning). Equally, we don’t own the CMS either; that falls to the remit of Website and Communications (WAC), who ran EdWeb 1 and now run its successor, EdWeb 2.
As we have a very large site, we’d been talking to WAC about the migration well in advance of the deadline. As part of our discussions, we agreed to take on a Lead Publisher role for not only our own Study sites, but also the smaller sites under the ‘Study’ umbrella (with their permission!). The hope was that in theory, WAC would just have one key liaison point for communicating changes and issues which we could then disseminate to anyone affected.
With great power comes great responsibility though, as I would ultimately be asked if everyone was happy in our sub-area to proceed – more on that later!
Migration 101: Steps, tools and tips
Step 1: Start as early as you can – foresight is the best kind of sight
We knew the scale of the project meant there was a lot of scope for issues to creep in during the process. This was why we spoke to Website and Communications early on, but also meant we could plan the stages.
As part of the preparation, I set up a very simple Planner board, with activities initially divided up into sections called ‘Pre-migration’, ‘During’ and ‘After migration’.
Planner is a task manager application, where individual items or tasks are allocated to different stages or themes using different columns. You can also use it as a Kanban board where things move through different stages (To do, Doing, Done) until the work is complete.
For this project, I used the board in the ‘what to do when’ style, ticking tasks off in each column once they were complete and moving on to the next batch of work.
By the time we reached the end of the migration, my columns were:
- To do
- Content spreadsheet and tasks (pre migration)
- 21 Nov to 4 Dec: Pre-live migration site checks
- BUGS – fix during migration
- Post-migration checks (4 Dec)
- Post migration long-list
- Comms
There’s various tools you can use for this sort of activity, but Planner is a nice easy one and included in our Office365 subscriptions (so free!). It was also flexible, so once I knew more about a particular task I could move it from one column to another (for example, if something actually should be done later or earlier in the process).
Lessons learned: I ♥ Planner
Nothing to say really, except I have a stronger appreciation of how even basic management tools can keep a complex project running smoothly!
Step 2: Stakeholder management
For this project, I had three types of stakeholders. One was the central WAC team coordinating the migration process for us. We needed to meet with them regularly to find out more about how the move would affect us, and to disseminate this information with our colleagues.
The second type of stakeholder was the objective bystanders – heads of areas that don’t have web management as part of their day-to-day, but who needed top-level information about how and when the project was happening in case it affected their teams.
The third was the active participants; colleagues who had login and publisher access to update and maintain their own subsites underneath /studying. I would need their support and engagement to review their own sites for any issues arising from their unique circumstances, but also to balance their requirements against actually getting things moved on time.
For stakeholder communications, it was important to treat these three groups differently.
Website owners and publishers
Site owners and publishers had the most active role, and the most communication from me. We liaised on general issues which I would share with the group if I suspected they’d affect everyone, but also individual consultations. These focused on identifying either things they could do first to reduce the amount of content migrating to the new system, or featured and dynamic content that might cause issues during the migration. These comms were very task- and practically orientated, as this is what the group needed to know.
Website and Communications
For this stakeholder I acted as something of a go-between, flagging the issues individuals from the owners and publishers group raised about their local sites. We then worked together to consider options which I could take back to the original team or individual and select the best approach. In this situation, I was balancing individual quirks and requirements with WAC’s more ‘global’ approach, while keeping in mind the practicalities and trying to avoid bespoke solutions where possible.
Objective bystanders
For the ‘objective bystander’ group, they just needed general details about when it was happening and who I’d spoken to in their teams about it – they didn’t need to know how to review their websites and feed that back.
Lessons learned: Democratic pragmatism and centralised decision-making
Overall, I think this part of the process has had a good legacy, in that I now have a stronger understanding of WAC’s processes as the overall owner of the service, but also a better appreciation of the problems my colleagues on local sites have been trying to address with their own websites.
As a result, we’ve been in regular contact since the migration as I try to offer support and guidance on how we can use the system in a consistent way that meets both prospective student and business needs.
Equally though, it was a lesson in centralised decision-making. While I tried to be a ‘benevolent’ go-between and balance everyone’s requirements, at the end of the day we had to migrate on time. If I suggested a delay to the migration because some parts of our sub-group wasn’t satisfied with something minor, there were larger risks for others migrating at the same time. Same too though, the centralised decisions have to go to the right people – we weren’t informed of a key delay to the project until the day it was supposed to happen.
I think I managed my part in this well, and communicated enough where things might not be perfect, but at the same time good enough to move on time – but more on that below.
Step 3: Be realistic about workload capacity
Once you enter into the active work phase, regardless of how well you’ll plan, there’s always unintended issues that can mean you don’t have enough time to do everything.
At that point, you need to prioritise: at the end of the day, what do you need to still be working? We had a few executive decisions to make about what was critical and what could wait till we switched (aware that this might be going into a pretty big backlog).
I continued to liaise with site owners about what would really affect them if it wasn’t working, and proposed workarounds in consultation with WAC that would help us change on time. In a lot of instances, there was a suitable change we could make that would resolve things to everyone’s satisfaction – just because it was always like this doesn’t mean you can’t compromise on a solution!
Equally though, we had to make sure it was good enough. We still pushed back on issues that genuinely weren’t functional, and happily got satisfactory solutions for these before the migration.
At the end, we also had a go/no-go session with WAC, where all key stakeholders signed off that they were happy for the change to take place. This was really useful, as it drew the metaphorical line in the sand in saying we were accepting the switch and where we might have to leave some things ‘unfinished’.
Lessons learned: Avoid single points of failure, and remember to define your minimum viable product
This was good practice for me as I prepared for the go-live of the new undergraduate degree finder in early March.
Technically it was a bit different; the EdWeb 2 migration was a hard deadline, but our undergraduate degree finder was a softer one that could in theory have moved.
However, while we hit exactly the same go/don’t go scenario on 3 March, we deemed it wasn’t practical to indeterminately delay something just because a couple of elements weren’t perfect. Obviously it’s different if something critical is wrong, but for more minor things, so long as it’s not misleading you also have to consider the downsides of a delay (and the effect on other teams).
In that case, we also had some scheduling issues due to my own availability, but thanks to good planning and a workload that was so well documented it could be shared across multiple members of the team, everything (mostly) went as we had hoped. Everything unresolved at that stage went into our own backlog, which we continue to revisit, prioritise, and maintain going forward.
The main lessons here were being clear about what represents a halt/no-go situation, and what can you live with? Much of the joy of iterative development and continuous improvement means you can keep tweaking your product – but it also sometimes means a hard decision to go live with something that’s not necessarily 100% what you had wanted.
As the saying goes, ‘Perfect is the enemy of good’. While we could have delayed launching undergraduate 2026, ultimately you’ll always need to get something out there, as no amount of pre-testing is going to give you the insights you get from real world users!
Final thoughts: economies of scale? Not quite!
As a project, this was a great lesson in seeing the impact of decentralisation. I originally thought there might be some economies of scale, where the same sorts of issues could get the same sort of fixes. But that wasn’t the case. Instead, we found:
- Everyone doing things differently, using unique tools to tackle similar challenges.
- ‘Everyone gets access if they do the training’ is a problem. I saw how editors had ballooned – many many users that aren’t being actively reviewed, trained, or updated. Some maybe only making minimal edits once every couple of years (by which time any training is a distant memory).
- Lots of legacy content that just needed removed full stop.
My brief spin around roughly 4,000 webpages cemented the recurring theme of a need for greater centralisation of core content. Time and again we’re duplicating because everyone wants it to sit on ‘their’ site, or just not aware that it’s already covered elsewhere. We can’t keep doing that.
While we’re a multi-layered, devolved institution, in the digital sphere we need to speak with (mostly) one voice. The prospective student doesn’t care that you sit in this team and I sit over here – they just want to know how to get things done.
That’s a strong theme I’ll take into managing the degree finder CMS and service going forward. We have a scale issue too – we have over 900 programmes across undergraduate and postgraduate, and we want to provide a place for those highly individual programmes to be marketed effectively and consistently. But a free-for-all isn’t the answer; with good planning, structure, and governance, we can and should improve our prospective students’ experiences and processes all round.
Read more about the development of our new provision for prospective students
