State government

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.

When the website is the public record: a regulator's statutory publication channel

The organisation behind these websites is a state economic regulator. Its work is public and procedural:

• it sets the maximum prices people pay for essential services
• it licenses some of the utilities that provide them
• it runs formal public reviews with consultation periods, submissions and hearings

Its website is not a brochure. It is the regulator's statutory publication channel, and a determination is published at the moment it appears there.

The organisations it regulates, and the lawyers who advise them, cite that site, and those citations are expected to keep resolving for years. So the content cannot simply be copied across. Every document has to arrive with its identity, its dates, its attachments and its editorial state intact, which makes a replatform a records problem long before it is a website problem.

Migration architecture and platform engineering inside a government programme

A partner agency led the programme and brought us in as their engineering partner for the move onto a government-managed Drupal(Opens in a new tab/window) platform. We worked across both properties, the regulator's main site and a second site for one of the schemes it administers, and provided:

• migration architecture
• platform development
• front-end engineering

Government delivery is rarely a single team. Several suppliers and the regulator's own developer all worked in the same codebase alongside the design and content teams, and keeping that shared build coherent was part of our work.

2 systems, a single set of documents, reconciled across 3 identifiers

The documents the site publishes did not live in the old website. They live in the regulator's enterprise records management system, held as formal records with their own numbers and revisions.

That left 2 sources describing the same material, each holding half the answer. The legacy site knew which document belonged to which review, in what order and on what date. The records system held the authoritative file.

The same document could also be known by 3 different identifiers, depending on which system you asked. So we built the reconciliation. A single lookup resolves a document across all 3 and settles which wins.

Anything the records system has not yet sent gets a placeholder, so a review can be assembled now and completed on the next sync.

A migration you can run more than once, without republishing what was withdrawn

A migration this size is never a single run. You run it, review what landed, correct something, run it again, and that only works if the second run recognises what the first one created.

Legacy pages were known by their web addresses, so we derived each item's identifier from its own path: same path, same identifier, every run. Reviews that reference other reviews are built in a second pass. For a client, that is the difference between a migration you can rehearse and one you get a single attempt at.

The decision we would lead with, though, is smaller and matters more. If an editor had unpublished a page, re-running the migration left it unpublished. On a regulator's site that is not a nicety: a withdrawn determination that quietly reappears is a regulatory problem, not a content bug.

And we proved the result rather than asserting it, comparing the source data against what actually landed in Drupal.

Where the regulator's publishing rules live: review types encoded in the site

Which documents appear under which tab of a review depends on the kind of review it is, and those rules belong to the regulator, so we encoded them in the site itself. An editor publishes a document once, sees only the fields that apply to that review type, and it lands where the rules say it should.

The public gets a timeline that opens at today, and every review page offers an accessible copy of a document on request. For a client, that means the publishing rules live in the platform rather than in a style guide someone has to remember.

What it added up to: a migration delivered in releases, not a single cutover

The work began in 2020 and the build ran across 2021, released more than 70 times inside that single year. That is a release rhythm rather than a big-bang cutover, which is what most government teams are quietly hoping for. The legacy address structure was kept wholesale, including the front page, so published citations pointed at addresses that still existed after the move.

More than 70 releases inside a single year, then 2 years of upgrades by the next team.

Then we handed it over, and it kept going: the team that received the platform carried on releasing and upgrading it through the next 2 years of Drupal work. For a migration, that is the outcome worth measuring. Not only that it landed, but that the next team could keep it moving.

For migrations where the content carries legal weight

Everything on this page is 4 of our services on one government replatform: migration architecture, platform development, front-end engineering, and the deployment work that put both sites on a government-managed platform.

If you run a regulator, a department, or any public body whose website is where decisions are formally published, this is the shape the engagement takes: the records reconciliation settled before the content moves, a migration that can be re-run without republishing anything withdrawn, and the legacy addresses kept so published citations still have somewhere to land. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If you are replatforming a site whose documents are cited elsewhere, and nobody can yet tell you what happens to those citations, send us the address structure you have to keep.

When the website is the public record: a regulator's statutory publication channel

The Independent Pricing and Regulatory Tribunal(Opens in a new tab/window) is the New South Wales independent economic regulator. Its statutory work includes:

• setting the maximum prices for water, public transport and council rates
• licensing private water utilities
• running formal public reviews with consultation periods, submissions and hearings

Its website is not a brochure. It is the regulator's statutory publication channel, and a determination is published at the moment it appears there.

Councils, utilities and the lawyers who advise them cite that site, and those citations are expected to keep resolving for years. So the content cannot simply be copied across.

Every document has to arrive with its identity, its dates, its attachments and its editorial state intact, which makes a replatform a records problem long before it is a website problem.

Our part in the programme: migration architecture on GovCMS

Salsa Digital(Opens in a new tab/window) led the programme and brought us in as their engineering partner for the move onto GovCMS(Opens in a new tab/window), the Australian government's shared Drupal(Opens in a new tab/window) platform.

We worked across both properties, the regulator's main site and the second site for the energy savings scheme it administers. Our part covered:

• migration architecture
• platform development
• front-end engineering

Government delivery is rarely a single team. Several suppliers, the regulator's own developer and the platform operator all worked in the same codebase alongside the design and content teams, and keeping that shared build coherent was part of our work.

2 systems, a single set of documents: reconciling the records

The documents the site publishes did not live in the old website. They live in the regulator's enterprise records management system, held as formal records with their own numbers and revisions.

That left 2 sources describing the same material, each holding half the answer. The legacy site knew which document belonged to which review, in what order and on what date. The records system held the authoritative file.

The same document could also be known by 3 different identifiers, depending on which system you asked. So we built the reconciliation.

A single lookup resolves a document across all 3 and settles which wins, and anything the records system has not yet sent gets a placeholder, so a review can be assembled now and completed on the next sync.

A migration you can run more than once, without republishing withdrawn content

A migration this size is never a single run. You run it, review what landed, correct something, run it again, and that only works if the second run recognises what the first one created.

Legacy pages were known by their web addresses, so we derived each item's identifier from its own path: same path, same identifier, every run. Reviews that reference other reviews are built in a second pass. For a client, that is the difference between a migration you can correct and one you have to redo.

The decision we would lead with, though, is smaller and matters more. If an editor had unpublished a page, re-running the migration left it unpublished.

On a regulator's site that is not a nicety: a withdrawn determination that quietly reappears is a regulatory problem, not a content bug. And we proved the result rather than asserting it, comparing the source data against what actually landed in Drupal.

Where the regulator's publishing rules live: encoded in the site

Which documents appear under which tab of a review depends on the kind of review it is, and those rules belong to the regulator, so we encoded them in the site itself.

An editor publishes a document once, sees only the fields that apply to that review type, and it lands where the rules say it should. For a client, that means the complexity sits in the platform rather than in an editor's training.

The public gets a timeline that opens at today, and review pages offer an accessible copy of a document on request.

What it added up to: 73 releases, then 2 years of upgrades

The work began in 2020 and the build ran across 2021, released 73 times inside that single year. That is a release rhythm rather than a big-bang cutover, which is what most government teams are quietly hoping for.

The legacy address structure was kept wholesale, including the front page, so the addresses behind inbound links and published citations were preserved rather than replaced.

Then we handed it over, and it kept going: the team that received the platform carried on releasing and upgrading it through the next 2 years of Drupal work.

73 releases inside a single year, then 2 more years of upgrades by the team that received it.

For a migration, that is the outcome worth measuring. Not only that it landed, but that the next team could keep it moving.

For migrations where the content carries the risk

Everything on this page is 3 of our services on one government replatform: migration architecture across 2 sources of truth, platform development on a shared government Drupal platform, and front-end engineering that put the regulator's own publishing rules into the site.

If you run a regulator, a department or any site whose content is the public record, this is the shape the engagement takes: a migration you can re-run and correct, editorial decisions preserved across re-runs, and legacy addresses carried across rather than dropped. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If your next replatform has to carry documents that live in a records system rather than in the website, tell us where your documents actually live.

Publishing the data is the easy half: what an open data portal needs after the files

If your organisation publishes data for the public to reuse, hosting the files is rarely what makes it hard. A spreadsheet on a server is a solved problem. The interesting questions all start after publication.

The same 3 questions come up on every portal.

• Someone needs a dataset you have not released yet. How do they ask, and how does anyone else see that the request was made?
• Someone spots an error in a column, or cannot work out how a figure was calculated. Where does that go, and does it end up attached to the data or lost in a generic contact form?
• A developer weighing up whether to build on your data has to judge, before investing any time, whether it is well maintained and licensed for their purpose.

Each of those is a real product problem, and none of them is solved by publishing more files.

Queensland's open data portal: CKAN and the extensions a government adds to it

The Queensland Government's open data portal, at data.qld.gov.au, publishes state datasets for public reuse. It is the practical expression of open data policy: anyone can find, download and reuse what a government agency holds, under a licence that permits it. Its readers are the public, journalists, researchers and businesses building products on public data, alongside the agency staff publishing it.

It runs on CKAN, the open-source data portal platform behind many national and state open data sites around the world. CKAN handles the catalogue itself. Everything a particular government needs on top of that is an extension, and Queensland maintains its extensions as public repositories anyone can read.

Alongside the portal sits the Queensland business services catalogue, the directory of services government offers to businesses. That one is Drupal(Opens in a new tab/window).

Our contribution, in the open: public CKAN repositories and a Drupal catalogue build

Between 2019 and 2021, engaged through Salsa Digital(Opens in a new tab/window), we contributed to the CKAN extensions behind the portal:

• the Queensland-specific behaviour that shapes the portal itself
• its theme
• the extensions that answer those 3 questions directly

Our changes sit alongside those of a much wider group of contributors, in repositories the Queensland Government owns and publishes itself.

That is a different working posture from a private client repository. Changes are visible, attributable and reviewed in public, by a community that did not hire you and has no particular reason to be polite about it. For a client, that posture reads as verifiable work: you can read the changes we made without taking our word for any of it.

Contributing successfully in that setting, in Python and CKAN rather than the PHP and Drupal we work in most days, is a credential in its own right.

On the business services catalogue we carried more of the load. We were the leading contributor to its Drupal build.

The 3 problems open data publishers keep hitting: requests, comments and certification

The extensions we worked on are worth understanding even if you never run CKAN: they are well-considered answers to the 3 questions above.

• Data requests turn a portal from one-way publishing into a demand signal. The public asks for datasets that have not been released, in the open, so agencies can see what people actually want rather than guessing at it.
• Dataset comments give quality feedback a home. A threaded discussion attached to the data itself means an error report or a methodology question lands where the next reader will see it.
• Third-party certification is the trust signal. Open Data Institute certificates rate a dataset's quality, licensing and sustainability against a published standard, so a developer can judge it without having to ask anyone.

Most organisations that publish data publicly run into the same 3 problems: a council, a regulator, a research body, a university. CKAN's answers to them are a useful reference even when the build in front of you is Drupal. For a client, that reads as time saved: the hard questions are already named, so a portal project starts at your own data rather than at first principles.

What the work left us with: maintained extensions and a second platform ecosystem

The portal is live, and the extensions are public, active and still maintained by the Queensland Government. For work of this shape that is the outcome that matters: the code stayed in service and other people kept building on it.

The extensions we contributed to between 2019 and 2021 are still public, active and maintained by the government that owns them.

For us it settled a question clients ask often. CKAN is Python, with its own community, its own extension model and its own deployment shape. Merged contributions in it answer "can you work outside Drupal?" concretely rather than with an assurance.

It also left us with a working understanding of open data as a domain. Those 3 problems are the first things we raise when a client tells us they are about to start publishing.

For organisations opening their data to the public

Everything on this page is one of our services in an unfamiliar setting: development, carried out in public repositories a state government owns, in Python and CKAN alongside the Drupal we work in most days.

If you run a council, a regulator, a research body or a university about to publish data for the public to reuse, this is the shape the engagement takes: the 3 questions answered before the build starts, work done in whatever ecosystem your portal already runs on, and changes anyone can read. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If you are standing up an open data portal, or running one where the datasets go out and nothing comes back, tell us what you publish and who needs it.

Government is organised by department. People are not: the case for one shared web platform

When you need something from government, you rarely know which department owns it. You know what you need: a permit, a payment, advice after a storm.

Yet a lot of government websites are still laid out the way the organisation is, because that is how digital tends to grow. One department at a time, each with its own site, its own supplier and its own way of publishing.

Victoria set out to change that. The Single Digital Presence programme aimed to bring 50 government websites onto one platform with one publishing standard, working to a principle that is still the clearest sentence we know on the subject: content belongs to the people who need it, not to the department that happens to own it.

What we built: the API layer, the multi-site engine and the testing architecture

Single Digital Presence is open source, and the record of who built what is public with it. Starting in 2017, we created most of the repositories behind the platform's Drupal(Opens in a new tab/window) layer, including its API layer, its multi-site engine and its testing architecture.

The pattern was the same across all of them. We laid the foundations before any feature work:

• the project scaffolding every repository is built from
• the continuous integration that runs on each change
• the automated tests over the behaviour that matters
• the developer workflow the teams work in day to day

The department's own team and its delivery partners then filled that structure with features. For a client, that order reads as a head start: whoever arrives next inherits a working pipeline instead of building one. The programme's technical lead credited the distribution and its testing approach from a conference stage in 2019.

In 2019 the Department of Premier and Cabinet contracted us directly, off the Victorian Government eServices Register, to write the developer documentation for the platform: how to work with the code, test an API endpoint and release a module. It shipped as a documentation site with a build that refuses to deploy if an internal link is broken.

One Drupal content system, many public websites: decoupled publishing with real preview

The heart of the platform is one Drupal content system serving many separate public websites, each with its own domain, brand, menus and homepage, all edited by agency staff in the same place. There is no separate installation per site.

A site is a piece of structured content, which makes bringing another agency on board a content decision, not a rebuild. For an agency joining later, that reads as a shorter path to launch: your site is configured on a platform that already runs, rather than procured and built again.

The public websites are rendered by a JavaScript front end, so Drupal serves content rather than pages. That split is good for performance and reuse, and it raises the question every organisation asks about decoupled publishing: how do editors preview their work when the content system renders nothing?

The platform's answer is one of the neatest we have seen, and it was not ours. The editor clicks Preview and lands on the real front end, which renders the unpublished draft exactly as the public will see it. We have carried that technique with us ever since.

Keeping a platform honest as it grows: shared testing across many repositories

The platform's Drupal code lives in many small repositories, each tested on its own. That is good for release safety and hard on consistency: every repository needs its own development environment, test harness and build pipeline, and copies of the same setup drift apart the moment nobody is watching.

We answered it in 2 pieces. The first was a shared test module giving every repository a neutral content type to write tests against, with a filter that scrubs its own fingerprints out of the site's exported configuration, so the test harness stays out of what the site ships. The second was a development toolkit that repositories fetch rather than copy: one small file each, one command surface, one place to change how everything is built and tested.

Where it got to: vic.gov.au, nearly a decade on

The platform is in service. vic.gov.au(Opens in a new tab/window) runs on it, its repositories are public and still active, and its front-end component library is published for anyone to install.

Each layer, hosting, content management and front end, was designed to be taken on its own, so another agency could adopt just the part it needed. Other Victorian agencies were building on the model within the first 2 years.

Nearly a decade after those first commits, vic.gov.au still runs on the platform.

The work outlived the engagement, and the teams who came after us could keep building on it. That is the outcome we care about most.

For governments bringing many websites onto one platform

Everything on this page is 3 of our services on one shared government platform: architecture for a multi-site Drupal system, development of the modules and the API layer behind it, and the DevOps that builds and tests every repository.

If you run a department, an agency, or a group of sites that each grew their own way, this is the shape the engagement takes: foundations first, tests and pipelines before features, and a platform layer other teams can build on. The same engineering is available with AI-assisted delivery where it suits the work, at the same tested standard.

If you are consolidating agency websites onto one publishing platform, or trying to keep a growing set of repositories consistent, tell us what your estate looks like.