Streamlining the migration of courses
We have just completed the migration of over 300 undergraduate and postgraduate courses from TerminalFour (T4) version 7 to version 8. A blog post describes how we automated parts of this migration, but we were still left with a lot of manual tidying up. This article describes how we ensured the final pages were ready for publishing to the new site.
As there were so many courses to check and update, it meant that the whole team had to be involved in carrying out the work. Therefore, it was vital that everyone understood what they were looking for and also consistent in making any changes before the work could begin.
A few members of the team drafted acceptance criteria that the rest of the team could follow. In our case, we had to check for things like:
- Apply the correct page layout to the section.
- Check against the original page in T4v7 to see if any images need to be migrated to the media library in T4v8.
- Edit the raw HTML that had been migrated to replace any references to images and documents with T4 media tags that linked to assets in the media library. In this way, we could ensure any associated assets would be published out.
- Update any section links to hard coded links that point users to content that still resides in T4v7.
- Check that all links work.
We then tested the acceptance criteria with a few courses to make sure we had not missed anything out before continuing with the quality assurance process.
An important aim was that the acceptance criteria should be sufficiently clear so that we would not have to go back over the courses to check that the changes had been made.
A Google spreadsheet listing every course that needed to be checked was created before work could begin. When individual team members started working on a course they marked the cell next to the course as ‘in progress’ followed by their name. After the work was complete, this was changed to ‘Done’. Another cell was used to record the time in minutes it took to complete the QA process.
We initially estimated it would take 30 minutes to QA each course, but after noting the actual time we realised that it was taking an average of 10 minutes per course. This then enabled us to modify the amount of work we could complete within our two week sprint.
It is important to note that each team member initially took longer to do each course as they had to familiarise themselves with the acceptance criteria and the task. Therefore, we acquired a few days data before modifying our estimate for how long it would take to complete the work.
Adopting this disciplined approach to the QA process meant that the work was completed efficiently and to a high standard. We hope that sharing this experience can help others who need to migrate content from one version of T4 to another.