When the platform will not let you write code: the GovCMS SaaS constraint
If you publish on a government platform, you have probably met the trade it makes. GovCMS, the Australian Government's whole-of-government Drupal(Opens in a new tab/window) service, gives agencies accreditation, compliance and managed hosting. In return, its software-as-a-service tier permits no custom code:
- no bespoke modules
- no server-side services
- nothing outside the vetted distribution
It is easy to read that as a wall. Almost every hard requirement a team has met before was answered by writing code, and here that answer is gone.
Our part in the work: architecture, build and migration engineering
A federal government department was moving its public web presence onto GovCMS, and its public channels carry the whole of what it does. A partner agency delivering that move brought us in as its engineering partner, with design carried by a separate studio.
We provided technical leadership, platform engineering and migration engineering:
- the scaffolding
- the content models
- the themes
- the deployment tooling
- the migration codebase itself
3 sites on one platform: a main channel, an intake site and a publication site
The engagement covered 3 sites on the same platform:
- the department's principal public channel, carrying reference information, publications, profiles, news, events and the programmes it funds
- a standalone public front door that takes structured reports from the public through a single intake form, live in 8 weeks
- a compact standalone publication site, shipped in 5 weeks alongside it
The main site's content model is built around the department's own subject matter, with its primary reference entities as first-class content rather than tags, so anything published can be placed against them.
Business logic that had to live in configuration: layout modifiers and design tokens
The most transferable piece is layout. Editors wanted per-section control over background images, gradients, colours, padding and height, at chosen breakpoints, so we modelled presentation as content.
Any component can carry any number of modifiers, each a small piece of content with its own media query, rendered as styling scoped to that component. An editor can combine a background image, extra top padding above tablet width and a minimum viewport height, without a developer and without code the platform would have refused. For a client, that reads as independence: your editors restyle a section themselves, and nobody has to ask first whether the platform will allow the code.
We took the same approach to the whole-of-government design system, re-theming it by assigning the department's design tokens into the system's own variables rather than overriding its output. Override the output and every release becomes a merge conflict. Assign tokens and it becomes a version bump.
We also restored the heading structure that paragraph-composed pages quietly lose, which screen readers rely on.
Moving 20 years of public content with no database to read
Roughly 20 years of published material had to move with the site: reference pages, publications, profiles, news releases and the document library behind them. There was no database to read and no API to call, so the source of record became the live public site, harvested and normalised into structured data.
That creates the problem any GovCMS team with a migration ahead of them is about to meet. A migration of this shape cannot be written without custom code, and the destination does not accept custom code. We resolved it architecturally: the migration ran as its own project on the platform-as-a-service tier, where custom code is permitted, and the content landed in the software-as-a-service site.
Archived material was treated as its own class throughout, because 20-year-old content does not have the shape of this morning's media release. And validation was written as configuration, committed beside the migration, so what landed could be checked against what was harvested.
Most migrations assert that they are correct. This one could be asked. For a client, that is the difference between being told a migration landed correctly and being able to check that it did.
What it adds up to: 10 months to build, 3 years of onward maintenance
The main site was built in about 10 months and went into service with 20 years of content behind it.
The measure we like most came later: it was still being maintained and upgraded 3 years after we handed it over, including a platform update and work toward a newer Drupal version, carried by the team that received it.
Built in 10 months, and still being maintained and upgraded 3 years after we handed it over.
A site still being improved by people who did not build it is solid evidence that it was built to be handed on.
For agencies that cannot ship custom code
Everything on this page is 5 of our services running inside one whole-of-government platform: architecture that puts the logic where the platform allows it, development of the content models and themes, the deployment tooling that ships them, migration engineering that could be checked against its source, and accessibility carried through the build.
If you publish on GovCMS software-as-a-service, or you are weighing a move onto it, this is the shape the engagement takes: requirements answered in configuration and theme rather than in modules you are not allowed to ship, a design system consumed by token assignment so an upgrade stays a version bump, and a migration that runs where custom code is permitted and lands where it is not. The same engineering is available with AI-assisted delivery where the work suits it, most obviously across migration mapping and validation.
If you have a requirement your GovCMS site will not let you build, tell us what it is and we will tell you where it can live.