GovCMS: when the platform will not let you write code
If you publish on a government platform, you have probably met the trade it makes. GovCMS(Opens in a new tab/window), 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: technical leadership and migration engineering with Salsa Digital
The Department of Foreign Affairs and Trade runs Australia's international relations, trade policy, development assistance and consular services, and its public web presence carries all of it. Salsa Digital(Opens in a new tab/window), delivering the move onto GovCMS, brought us in as its engineering partner, with design carried by a separate studio.
We provided technical leadership, platform engineering and migration engineering:
- the project scaffolding and the deployment tooling
- the content models behind all 3 sites
- the themes, including the design-system work
- the migration codebase itself
3 GovCMS sites for a department with a global remit
The department's public presence was built as 3 sites.
- the corporate site, its main public channel, carrying country and regional information, publications, profiles, news, events and the programmes it funds
- tradebarriers.gov.au, the national front door where Australian exporters report the obstacles they meet in overseas markets that are not tariffs: quarantine rules, labelling requirements, customs delays. It takes reports through a single structured intake form, and was live in 8 weeks
- a site for the Cairns Group, the coalition of agricultural exporting nations chaired by Australia, shipped in 5 weeks
The corporate site's content model is shaped like a foreign ministry, with country pages as first-class content rather than tags, so anything published can be placed geographically.
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 change how a page looks without booking developer time.
We took the same approach to the Australian 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: a migration built where custom code is allowed
Roughly 20 years of published material had to move with the site: country 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.
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 trusting a migration and being able to check it.
What it adds up to: 10 months to build, still maintained 3 years on
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 about 10 months with 20 years of content behind it, and still being upgraded 3 years after handover.
A site still being improved by people who did not build it is strong evidence that it was built to be handed on.
For teams publishing inside a platform they cannot extend
Everything on this page is 5 of our services running inside a platform that permits no custom code: architecture that puts business logic in configuration, development within a vetted distribution, migration at 20-year scale, DevOps and hosting through the platform's own tooling, and accessibility work carried in the theme.
If you publish on GovCMS, or on any accredited government platform that fixes what you are allowed to build, this is the shape the engagement takes: presentation modelled as content so editors keep control, design-system work done by assigning tokens rather than overriding output, and a migration that can be checked rather than trusted. The same engineering is available with AI-assisted delivery where it suits the work.
If your GovCMS build has a requirement the software-as-a-service tier will not let you code your way out of, tell us what the platform is blocking.