A university web platform is never finished: upgrades, new brands and content migrations
A university website carries a decade of accumulated content, an audience that never accepts an outage as an explanation, and a platform that reaches end of life on a schedule somebody else set. There is always a version to upgrade, a brand to stand up, content to bring home.
Most of that work arrives irregularly and none of it can be deferred, which is an awkward shape to hire for. Victoria University(Opens in a new tab/window) runs its own Web Services team in Melbourne and brings in specialists for the peaks. We have been one of them since 2017.
Working alongside the university's own team: platform engineering from Drupal 7 to Drupal 11
The university's team owns the estate day to day. We provide the platform engineering, the architecture and the delivery practice underneath it, and we hand over what we build as we go. Building technical understanding inside their team has been part of the arrangement from the first year, not something bolted on at the end.
In practice that means:
- a build that runs on Vortex(Opens in a new tab/window), our open-source Drupal project template
- preview environments that appear per change
- automated testing
- release tooling
- hosting
- a rolling programme of upgrades that has carried the estate from Drupal(Opens in a new tab/window) 7 to Drupal 10 and now Drupal 11
For a client, that reads as capacity without a handover cliff: the specialists arrive for the peak, and what they built stays understood inside your own team.
New brands, and content brought home: a vocational site and an institute migration
The university's vocational brand had been sitting inside the main site as a section of it. We built it out as its own website on its own domain, with the university's own team moving the content across.
A few years later we consolidated the separate site of one of the university's policy institutes into the main site. A research institute's whole value is its published papers and the authors attached to them.
So instead of writing scripts for 2 months and finding out on launch night whether they covered everything, we ran the migration continuously throughout the build, proving it against the real content every day. For a client, that turns launch night into a rehearsal you have already run rather than the first full test.
Researcher profiles people can actually find: a searchable directory of academics
An academic profile is commercial infrastructure for a university rather than a vanity page. It is how:
- an industry partner finds a collaborator
- a research student picks a supervisor
- a journalist finds someone to comment
Working to the university's own requirements, our team built its public directory of academics: a profile the academics drive themselves through an editorial workflow, and a search that finds people by expertise rather than by name. Publications, grants and supervision history arrive from the university's own systems, and the rest belongs to the academic to write.
For anything opt-in, adoption is the number that matters. Within weeks of launch, 271 of the 354 academics in scope had a published profile.
Moving the whole platform with no planned downtime: the Lagoon hosting migration
In 2021 both public websites moved onto one hosting platform, amazee.io Lagoon, and every non-production and preview environment moved with them. That second part is the difference between relocating a website and moving a team's whole way of working.
There was no planned downtime, and that came from sequencing rather than heroics. Each site was stood up on the new platform first, its integrations moved and tested there, and the university's team validated it with their own tooling and acceptance testing before traffic followed. Publishing paused for a business day.
What 9 years adds up to: 3 measured results and 2 open-source tools
3 pieces of this work have a number on both sides of them.
- Long-lived sites accumulate weight, and the weight is usually not growth. Most of what was sitting in this one's database turned out to be historical data nothing referenced any more, and removing it left the database 63 per cent smaller.
- Editors on large sites often wait hours for a published change to appear. We measured that end to end and brought the worst case down from most of a day to about 20 minutes.
- Asked to speed up a test suite that took close to 30 minutes, we found 3 of our 4 assumptions about the cause were wrong: the tests were waiting on third-party assets, not on the application. That path ended up about 3 times faster.
A database 63 per cent smaller, and a published change live in about 20 minutes instead of most of a day.
Some of it has come back out as open source. The deployment tooling we first wrote here became drevops/git-artifact(Opens in a new tab/window). And the practice of shipping the development database inside a Docker image, born on this platform so every developer and pipeline starts from real data, grew into drevops/mariadb-drupal-data(Opens in a new tab/window).
9 years, continuous, across 3 generations of architecture. In a market where suppliers rotate every couple of years, that is the outcome we are proudest of.
For web estates that outlive their suppliers
Everything on this page is 4 of our services running on one university estate: development alongside an in-house team, migration of content and of whole platforms, DevOps and hosting, and the training and handover that leaves the knowledge inside the client's team.
If you run a university, a TAFE or another estate that has to keep serving while it changes underneath, this is the shape the engagement takes: specialists who arrive for the peaks, a rolling upgrade programme instead of a rebuild, migrations rehearsed against the real content, and the knowledge left with your own team. The same engineering is available with AI-assisted delivery where the work suits it, at the same tested standard.
If your estate has a Drupal site heading toward end of life, or content sitting in a separate site that should not have one any more, tell us what is on the platform.