Breaking the Dead End: Migrating GovCMS8 UIKit Starter to Drupal 11

If you’re running the GovCMS8 UIKit Starter theme, you’re sitting on a ticking time bomb. The DTA UI Kit packages it depends on were abandoned in 2019. There’s no official upgrade path. Your security audits fail. And Drupal 11 is here, with Drupal 12 on the horizon.

At TrueCMS, several customers rely on this theme for critical services. We turned a years‑old problem into a manageable migration path that buys time to modernise properly — with zero design change and zero npm vulnerabilities.

The problem: a theme frozen in time

The GovCMS8 UIKit Starter was the standard for Australian government sites. Built on the DTA’s Design System Components, it served its purpose well. Then everything stopped.

What went wrong

• 2019: DTA deprecated the @gov.au/* packages.

• 2020–2024: agencies accumulated technical debt with per‑repo patches.

• Today: sites often fail security audits with 100+ vulnerabilities.

• Note: Drupal 9 reached EOL in November 2023; Drupal 10 reaches EOL in 2026.

The real cost

Operational risks and business impact of staying on the legacy UIKit stack

Impact	Current state	Business risk
Security vulnerabilities	100+ known CVEs in npm audit	IRAP compliance failures, potential breaches
Development velocity	Slow builds, Node conflicts	Longer timelines, developer frustration
Maintenance burden	Custom patches per repo	Exponential technical‑debt growth
Platform support	Incompatible with modern hosting	Forced infrastructure compromises

The solution: TrueCMS‑maintained packages

We modernised the entire UIKit ecosystem while preserving the public API and markup. Customers running on our maintained packages see a 100% reduction in npm vulnerabilities.

What this means in practice:

• Same HTML markup, CSS classes, component APIs, Pancake workflow, and visual appearance.

• Modern dependency trees, current Node/npm support, eliminated security vulnerabilities, and Drupal 11 compatibility.

Implementation: a 30‑minute migration

The beauty of this approach? Implementation takes minutes, not months.

Before: your current package.json

{
  "dependencies": {
    "@gov.au/accordion": "x.y.z",
    "@gov.au/body": "x.y.z",
    "@gov.au/buttons": "x.y.z",
    "@gov.au/core": "x.y.z",
    "@gov.au/footer": "x.y.z",
    "@gov.au/grid-12": "x.y.z",
    "@gov.au/header": "x.y.z",
    "@gov.au/main-nav": "x.y.z",
    "@gov.au/page-alerts": "x.y.z",
    "@gov.au/side-nav": "x.y.z",
    "@gov.au/skip-link": "x.y.z",
    "@gov.au/tags": "x.y.z",
    "@gov.au/text-inputs": "x.y.z"
  }
}

Example npm audit: ❌ 127 vulnerabilities (moderate/high/critical).

After: TrueCMS‑maintained packages

{
  "dependencies": {
    "@truecms/accordion": "^8.0.2",
    "@truecms/animate": "^2.0.2",
    "@truecms/body": "^3.0.2",
    "@truecms/breadcrumbs": "^4.0.2",
    "@truecms/buttons": "^4.0.2",
    "@truecms/callout": "^4.0.2",
    "@truecms/card": "^1.0.2",
    "@truecms/control-input": "^4.0.2",
    "@truecms/core": "^5.0.2",
    "@truecms/cta-link": "^3.0.2",
    "@truecms/direction-links": "^4.0.2",
    "@truecms/footer": "^4.0.2",
    "@truecms/form": "^1.0.2",
    "@truecms/grid-12": "^3.0.2",
    "@truecms/header": "^5.0.2",
    "@truecms/headings": "^3.0.2",
    "@truecms/inpage-nav": "^4.0.2",
    "@truecms/keyword-list": "^4.0.2",
    "@truecms/link-list": "^4.0.2",
    "@truecms/main-nav": "^2.0.2",
    "@truecms/page-alerts": "^3.0.2",
    "@truecms/pancake": "^2.0.0",
    "@truecms/pancake-sass": "^3.0.0",
    "@truecms/progress-indicator": "^4.0.2",
    "@truecms/responsive-media": "^3.0.2",
    "@truecms/select": "^3.0.2",
    "@truecms/side-nav": "^6.0.2",
    "@truecms/skip-link": "^3.0.2",
    "@truecms/tags": "^5.0.2",
    "@truecms/text-inputs": "^3.0.2"
  }
}

Example npm audit: ✅ 0 vulnerabilities.

Migration steps

# 1) Replace @gov.au/* dependencies with @truecms/* in package.json

# 2) Clean install
rm -rf node_modules package-lock.json
npm install

# 3) Update direct import references (example)
# Find:    import '@gov.au/core/lib/js/a11y.js'
# Replace: import '@truecms/core/lib/js/a11y.js'

# 4) Rebuild assets
npm run build

# 5) Test and deploy
drush cr

Drupal 11 compatibility

Our packages align with Drupal 11 requirements:

Compatibility of TrueCMS packages with Drupal 11 stack

Requirement	TrueCMS packages
Node.js 22+	✅ Fully compatible
npm 9+	✅ Native support
PHP 8.3	✅ No conflicts
Twig 3	✅ Templates unchanged
CKEditor 5	✅ Styles maintained

The bridge strategy: buy time, plan properly

This isn’t about avoiding modernisation — it’s about doing it right.

A pragmatic timeline

Cost comparison

Time, risk, and budget comparison of migration options

Approach	Time to Drupal 11	Risk level	Budget impact
Full redesign now	6–12 months	High (everything changes)	$$$$
Keep patching legacy	Never (dead end)	Critical (security debt)	$$$ (ongoing)
TrueCMS bridge	1–2 weeks	Low (nothing changes)	$ (one‑time)

Results from the field

• Migration time: ~2 weeks on average (including testing).

• Vulnerability reduction: 100% (from 100+ to zero).

• Build time improvement: up to 3× faster.

• Developer satisfaction: no more brittle workarounds.

Open‑source commitment

• Component Library

• Build Tools

• NPM Packages

• Component Catalogue

Community invitation

We'd love your feedback. Try the @truecms/* packages on a branch, and tell us how the migration goes. Open an issue or PR at GitHub, or share your experience via the contact form so we can improve the packages and docs for everyone.

Frequently asked questions

Will this change how our site looks?

No. We maintain complete visual and functional parity. The only changes are under the hood — modern, secure dependencies replacing abandoned ones.

How long will TrueCMS maintain these packages?

We’re committed to maintaining these packages through Drupal 12’s end‑of‑life (approx. 2028). That gives you years to plan a proper move to a modern design system like CivicTheme.

What if we have custom modifications to the UIKit Starter?

Sub‑themes and customisations continue to work. Since APIs and class names are preserved, your overrides remain compatible.

Can we migrate components gradually?

Yes. You can run both @gov.au and @truecms packages during transition if needed. We still recommend a complete swap to eliminate vulnerabilities.

What about accessibility?

All original WCAG 2.1 AA compliance is maintained. We haven’t added new accessibility features, and we haven’t removed any either.

Is this a long‑term solution?

This is a bridge solution that buys time to modernise safely. It reduces risk and technical debt while you plan a design‑system transition.

Take action: break free from the dead end

With TrueCMS‑maintained packages you can:

• ✅ Achieve Drupal 11 compatibility in weeks, not months.

• ✅ Eliminate npm vulnerabilities.

• ✅ Reduce build friction and developer toil.

• ✅ Buy time to plan a proper modernisation.

---

Security note: Panelizer deprecation

Many GovCMS8 UIKit implementations also rely on Panelizer, which has since been deprecated due to unresolved security issues. If your site still uses Panelizer, we recommend planning a remediation path as part of (or alongside) your UI Kit package swap and Drupal 11 upgrade. Typical approaches include replacing Panelizer with supported patterns (e.g. Layout Builder, Paragraphs, or slot‑based templates) and migrating affected displays with automated checks to prevent regressions.

Need help remediating risk? Talk to us about a fast audit and remediation plan covering Panelizer removal and other security vulnerabilities surfaced by npm audit or code scans. Contact us at /contact to book an assessment and receive a practical, low‑risk path to green.

Technical references

Originals and future paths for context:

• GovCMS8 UIKit Starter

• Legacy DTA Components

• Archived documentation (DTA Design System)

• CivicTheme