When a website is where people go for health, housing and concessions
People arrive at a health and human services website with a real question, often at a difficult moment:
- someone checking whether they qualify for a concession
- a parent trying to understand a family service
- a nurse looking up clinical guidance
- an adult asking for the records of their own childhood in care
The site either answers the question or it does not.
The Victorian Department of Health and Human Services ran one of the largest web estates in the state, covering consumer health information, concessions, housing, disability, family services, records access, and clinical guidance for the health sector. Many audiences, many editorial teams, one shared expectation that the information will be right and reachable.
Drupal engineering inside the Salsa Digital partnership
The work reached us through Salsa Digital(Opens in a new tab/window), a government digital agency whose teams carried strategy, design and content across the department's properties. We joined as their engineering partner and stayed for 4 years, providing:
- platform engineering
- build and release tooling
- Drupal(Opens in a new tab/window) development
- content migration
- decoupled front-end work
Some of it was new architecture. A lot of it was the quieter work of making several teams' releases predictable.
Several audiences, one Drupal codebase and one content platform
3 of the department's public websites, serving citizens, funded organisations and service providers, were consolidated into a single Drupal codebase. One map of the estate drives everything downstream: the build, each site's settings, deployment, the test suite and the theme. Each site keeps its own visual identity through configuration rather than code, so an editorial team can change how their site looks without waiting for a developer release.
A separate content platform then decoupled the department's content from its presentation, so several front ends could share one editorial spine. It carried a consumer health encyclopaedia, professional guidance published as open data, service directories with eligibility and access details, and a records access service. Editors describe intent, such as whether a page offers text to speech or a printable version, and each front end decides how to honour it.
Built for the people on the other end: accessibility and a link-safe migration
The front ends built on that platform are server-rendered JavaScript applications, and 2 things matter about how they behave. Every part of a page is assembled independently, so one troublesome component degrades on its own instead of taking the page with it.
The second is accessibility, treated as implementation rather than aspiration:
- screen-reader headings
- focus management on dialogs
- proper tab and panel semantics for medical citations
- built-in text to speech
Migration mattered for the same reason. People bookmark government pages, print them, cite them in letters and share them in community groups, and search engines have years of them indexed.
The migration was built so those links survived: content from the legacy system was rebuilt as structured, reusable page components, and old-style page and document addresses were resolved on the new platform and served the right file. For a client, that is what a link-safe migration buys: the address saved in a bookmark or printed in a letter still leads somewhere after launch day.
Built once, released safely: containers and continuous integration
Underneath all of it we changed how the code was built and shipped. In 6 days in 2018, a live government Drupal site moved onto containers and managed dependencies, with the application built exactly once, in continuous integration, and that identical build used everywhere afterwards.
One self-documenting set of commands ran it, so every developer and the pipeline did the same thing. Releases were designed to fail quietly: a dry run by default, and a release that did not complete cleanly left visitors seeing the site exactly as it was. For a client, that is what a safe release means: a release that does not land costs you a wait, not a broken site.
What it left behind: 2 open-source tools still shipping
We worked across 4 of the department's properties over 4 years, and the tooling outlived the engagement.
2 things that began as answers to real problems on these sites are open source today and still maintained. drevops/behat-steps(Opens in a new tab/window), a library of reusable automated test steps for Drupal, was extracted from the department's sport and recreation site and later became a dependency of the Victorian Government's central content platform.
And the containerised project template built in that week in 2018 is the direct ancestor of Vortex(Opens in a new tab/window), the open-source Drupal project template we ship on every project today.
4 properties over 4 years, and 2 of the tools built for them are open source and maintained today.
That is the part we are proudest of: solving a real problem twice, then giving the answer away.
For government estates where the information has to be right
Everything on this page is 4 of our services running across one government web estate: architecture and development on a shared Drupal codebase, content migration that keeps the addresses people already have, build and release engineering, and accessibility built in rather than bolted on.
If you run a government web estate, a health service, or several public sites that share one editorial team, this is the shape the engagement takes: one codebase behind several sites, migrations that keep existing addresses resolving, and releases safe enough to be routine. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.
If your estate has spread across several ageing sites, or a migration is coming and the links people already have worry you, tell us what the estate looks like.