> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-portal/from-concept-to-production-choose-your-cms.md). # From Concept to Production: Choose Your CMS A six-step selection process and evaluation framework for choosing a government CMS platform, with real government examples. You need a CMS that your team can actually maintain, that scales as you grow, and that your government can govern long-term. The GovStack CMS Building Block defines ten core capabilities. Several open-source platforms meet them. The real choice isn't between features — it's between support models and architectures that work for government, and those that create headaches years down the road. This page shows what works, what doesn't, and how to decide. {% hint style="info" %} For the full list of capabilities, see [The Playbook](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs.md). For technical architecture and specification detail, see the [Technical Deep Dive](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs/technical-deep-dive.md). {% endhint %} ## 6 Steps to Choose 1. **Define what you need.** Engage IT, communications, and administration. What does your government actually require? Multi-language? Integration with existing systems? Accessibility? 2. **Research what works.** Look at platforms already used in similar government contexts. 3. **Check customization and integration.** Can it adapt to your branding? Can it connect to your ERP, CRM, identity systems, and workflows? 4. **Verify accessibility is built in.** WCAG 2.2 AA compliance must be native, not added later. 5. **Calculate real costs.** Include hosting, security updates, training, and staff time over 5+ years. Cheap platforms often become expensive ones. 6. **Choose your service provider carefully.** The service provider matters as much as the CMS. They will train your team and build your capacity. ## What Doesn't Work {% hint style="warning" %} * **Too many plugins.** Hundreds of independently maintained add-ons = security chaos. You can't patch everything at once, and compliance breaks. * **No maintainability.** If only specialized developers can maintain it, you're dependent forever. When the vendor disappears, so does your system. * **Proprietary lock-in.** Closed-source, licensing fees, rising costs, limited flexibility. Open-source platforms give you control and freedom. * **Accessibility as an afterthought.** If it's not built in from day one, you'll spend years and money retrofitting. For government, this is unacceptable. {% endhint %} ## What Works: Real Government Examples ### TYPO3: Consolidation at Scale Rwanda runs over 200 government sites on a single TYPO3 multitenancy instance. One team, one security update cycle, consistent governance across all agencies. When Rwanda patches TYPO3, all 200+ sites are secure at once. When they change a permission, it applies everywhere. No coordination chaos. Germany made TYPO3 its national standard for government digital services. Rather than each ministry choosing different platforms, they unified on TYPO3 — giving each team a modern platform while ensuring consistent governance and shared expertise across government. **Why this works:** One update cycle. One team. Consistent experience for citizens. Lower costs. One governance model applied everywhere. ### Drupal: Flexibility and Independence The White House and 15+ US government agencies run Drupal. They chose it because each agency can customize workflows, content models, and user experience without touching core code. **Why this works:** Each agency stays independent but shares infrastructure. You can adapt to unique requirements without waiting for a vendor. Open-source, no licensing traps. ## Your Service Provider Matters More Than You Think A good CMS with a bad service provider fails. A decent CMS with a good service provider succeeds. {% columns %} {% column width="50%" %} **Good service provider** Government experience. Trains your team. Builds capacity, not dependency. Stays after go-live. {% endcolumn %} {% column width="50%" %} **Bad service provider** Delivers something your team can't understand. No training. Disappears after launch. {% endcolumn %} {% endcolumns %} {% hint style="success" %} **Bottom line:** A platform you can maintain beats a "perfect" platform you can't. {% endhint %} ## How to Evaluate Any Platform **The 10 Core Capabilities** (from [The Playbook](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs.md)): for a detailed explanation of each capability and validation criteria, see The Playbook: What Every Government CMS Needs. In brief: Can non-technical staff publish? Can you manage multiple sites? Does it maintain link integrity? Is security modern? Can multiple organizations share safely? Is WCAG 2.2 AA built in? Can it integrate? Can you customize without changing core code? Will it scale? Can you upgrade without breaking things? **Security and Maintenance:** Is it maintained by a dedicated team? Can you get security announcements? Is there a documented vulnerability process? **Community, Documentation, Support:** Active community? Documentation available in a language your team works with? Training programs? Can you find a service provider — locally or globally? **Capacity Building (Most Important):** Can your team realistically learn it? Can you hire new people if needed? Will the service provider build your team's capability or create permanent dependency? If you can't build local expertise, you're stuck with external support forever. **Your Governance Structure:** * Single ministry, multiple sites? You need multi-website capability. Don't use single-site CMS or you'll end up with different platforms for each site (nightmare to maintain). * Multiple agencies, one platform? Multitenancy is essential. One team, one security cycle, consistent governance. * Separate platforms? Then integration capabilities matter most. How will they share data? **Integration Needs:** What systems must it connect to? (Workflows, registries, identity, other services.) All modern open-source platforms integrate — ease varies. ## Next Steps 1. Read [The Playbook](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs.md) to understand the ten core capabilities in depth. 2. Research what's available. Apply the evaluation framework to platforms used in your country or region. For technical specification detail, see the [Technical Deep Dive](/experience-digital-transformation/government-portal/the-playbook-what-every-government-cms-needs/technical-deep-dive.md) if your team needs to assess API architecture, data models, or compliance requirements. 3. Assess your team's learning capacity. Don't choose based on what they already know — choose based on what they can realistically learn and what support you can access. 4. Run a proof of concept. Build one small site with your top candidate. Can your team work with it? Does the service provider deliver on their promises? 5. Plan for scale. Once you've chosen, plan multitenancy and governance. See [Scale From 1 Portal to 100: Multitenancy Explained](/experience-digital-transformation/government-portal/scale-from-1-portal-to-100-multitenancy-explained.md). {% hint style="success" %} Remember: The right platform is the one your team can learn, you can find implementation support for (locally or globally), and your governance model can scale on. {% endhint %} ## Sources * Rwanda Government Portal Implementation Report — TYPO3 * TYPO3 Government Site Builder Solutions — TYPO3 * German Government CMS Switches to TYPO3 — Interoperable Europe Portal * Whitehouse.gov Using Drupal — Dries Buytaert * Top Fifteen Governments and Agencies Using Drupal — The DropTimes * Why Government Agencies Deploy Drupal — Pantheon --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/government-portal/from-concept-to-production-choose-your-cms.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.