Choosing a Self-Hosted CMS for a Publishing Team: Test the Editorial Lifecycle
Compare self-hosted CMS options by running your real publishing work through them—from first draft and approval to correction, export and ongoing maintenance.
Why workflow fit matters more than a feature checklist
A CMS can list features that sound right and still make everyday publishing awkward. The useful question is not simply whether a platform has drafts, roles or scheduling. It is whether your team can complete its actual work clearly, with the right people involved and without avoidable workarounds.
Treat WordPress, Drupal, Ghost or any other candidate as something to test, not as a conclusion to reach from its name or feature list. The supplied evidence does not establish which platform is best for a publishing team, or what any specific current version supports. Verify capabilities in the version and configuration you would actually use.
- Evaluate a complete task, not an isolated feature.
- Use the same test content, people and acceptance criteria for every candidate.
- Record workarounds, unclear handoffs and required configuration alongside successful outcomes.
Map the publishing lifecycle, including exceptions
Before opening a demo, write down how a representative item moves through your team. Include the routine path and the situations that interrupt it. A simple map might start with an assignment or idea, continue through drafting and review, then cover approval, publication and later maintenance. Adapt the stages to your process rather than assuming every team follows the same sequence.
Ask each role to describe what they receive, what they change, what they decide and how they know the next person can act. Include exceptions such as a reviewer being unavailable, a correction arriving after publication, an item needing a later date, or a draft being paused. These are useful tests precisely because a tidy demonstration may not show them.
- Name each stage, responsible role, handoff and expected outcome.
- Mark which steps are mandatory and which depend on content type or risk.
- List common exceptions, including rejected drafts, urgent corrections and changed publication dates.
- Agree on what a successful handoff looks like before comparing systems.
Build a representative test set
Choose test material that reflects the work your CMS must support. A single short article is rarely enough to reveal how the system handles different structures, contributors or review needs. Use sample content rather than sensitive live material unless your organization has approved the test environment for it.
Keep the test set manageable but varied. Include the content types your team publishes, the kinds of assets or links used, and any recurring content that must appear in more than one place. Add test users corresponding to real responsibilities, such as author, editor, approver and administrator. Do not assume that a role label means the person can perform only the actions you intend; test access directly.
- Select a routine item, a complex item and one that needs a correction.
- Include the contributors and reviewers who represent your real handoffs.
- Use examples with different review paths or publication timing where applicable.
- Write down expected results before testing so the team can compare consistently.
Test drafting, review, approval and previews
Run a complete draft-to-decision exercise. Have one person create or edit the test item, another review it, and the appropriate person make the publication decision. Observe whether each participant can tell what is expected next and whether the team can distinguish a draft, an item awaiting review and an approved item in its actual workflow.
Test previews with the people who rely on them. Check whether reviewers can assess the content in a presentation that is useful for their decisions, and whether changes made after review are easy for the team to identify. Verify the behavior for the candidate’s current version and configuration; do not infer preview or approval capabilities from a product description alone.
- Can the writer identify who should review the item and what is still outstanding?
- Can a reviewer provide a decision or feedback in the expected way?
- Can the team tell whether requested changes have been made?
- Does the preview support the review task, including relevant layout and linked material?
- Can you explain what happens when a reviewer rejects, pauses or returns a draft?
Test revisions, scheduling, corrections and reuse
A publishing lifecycle continues after approval. Test how the team works with changes over time: revise an item, compare the changed version with the earlier one, and determine what information your team can use to understand the change. Confirm the available behavior directly rather than assuming revision history or comparison works in a particular way.
If your team schedules publication, run a test that includes setting, changing and cancelling a planned publication. Check how the responsible people can confirm the intended timing and what they do if the schedule changes. For corrections, test the full path from identifying an issue to approving and publishing a fix. For reused content, identify the source of truth and test how an update is handled wherever that content appears.
- Can the team review prior changes in a way that supports its correction process?
- Can the responsible person verify, change or cancel the planned publication as needed?
- Is a post-publication correction clearly assigned, reviewed and confirmed?
- When content is reused, can staff identify where it appears and how updates are managed?
- Record any manual steps, duplicated content or unclear ownership.
Check roles and handoffs against real responsibilities
Start with responsibilities, not the CMS’s role names. Make a short access matrix showing who may create, edit, review, approve, publish and manage settings. Then test each representative account against that matrix. Confirm both that people can do the work they need and that they cannot perform actions your policy reserves for someone else.
Include temporary and less common situations, such as a contributor leaving, a reviewer covering for a colleague or an administrator helping with a blocked item. Determine who will request, approve and remove access. A workflow that depends on one person’s account or informal knowledge may be difficult to maintain even when the main path works.
- List job responsibilities and required actions before mapping them to system roles.
- Test access using separate accounts rather than relying on an administrator’s view.
- Check whether handoffs remain understandable when a participant is unavailable.
- Document who owns account changes and workflow decisions.
Assess migration, export and long-term content ownership
A CMS choice affects more than the first publication. Before committing, identify what the team may need to move or retain: content, media, links, structure, metadata and records of editorial decisions. Ask the vendor or project documentation what export options exist, then run a small practical test with representative material. Do not treat an export button or a general claim of portability as proof that the result will meet your needs.
Define what a useful exit looks like for your organization. Can the team inspect the exported material? Does it preserve the information you need? What would require manual work or a separate process? The answers depend on your content and retention requirements, so make them explicit rather than assuming that every CMS handles migration the same way.
- List the content and related information that must be retained or moved.
- Test export with more than one content type and include associated media where relevant.
- Review the result with the people responsible for future migration or records.
- Document what is not included, what needs transformation and who owns that work.
Include hosting and maintenance in the decision
A self-hosted CMS means the organization must decide who is responsible for the surrounding service as well as the editorial experience. Clarify who manages the server and application, who checks backups and restoration procedures, who controls access, and who decides how maintenance is handled. A platform that suits the editors may still be a poor fit if the required operational ownership is unavailable.
Managed deployment can change who handles parts of the infrastructure, but it does not remove customer responsibilities for content, access decisions, governance or understanding recovery needs. For example, Airbip offers managed deployment of catalog applications as Docker workloads on Airbip cloud servers, with routing and TLS certificates automated through Traefik and Let’s Encrypt. It also provides DNS checks, service lifecycle management and configurable daily, weekly and monthly backups. Confirm the live Airbip website for current plans and commercial terms, and establish how your own data, access and recovery requirements will be handled.
- Assign responsibility for application and infrastructure tasks before launch.
- Ask how backups are configured and how your team would verify a restoration.
- Agree who manages access, domains, content governance and incident decisions.
- Choose a deployment model that matches your team’s operational capacity and control requirements.
Frequently asked questions
How should a publishing team compare self-hosted CMS options?
Map the team’s actual lifecycle, then run the same representative tasks in each candidate. Include routine publishing and exceptions such as returned drafts, changed schedules and post-publication corrections. Record outcomes, workarounds, configuration needs and unanswered questions.
Should a team choose WordPress, Drupal or Ghost for editorial workflows?
The supplied evidence does not support a platform ranking or a claim that one is best for a particular team. Test each candidate in the version and configuration you would use, against your content types, roles, review process and operational requirements.
What should we test in a CMS preview?
Ask whether the people responsible for review can assess the content in a useful presentation, including relevant layout and linked material. Test changes made after review and confirm how the team can tell what is ready for approval.
How can we assess content export before choosing a CMS?
List the content and related information you need to retain, then run a small export using representative material. Inspect the result with the people responsible for migration or records, and document omissions, transformations and manual work.
Does managed hosting remove the team’s responsibility for a self-hosted CMS?
No. Managed deployment can handle parts of the infrastructure, but the organization still needs to make decisions about its data, access, governance and recovery requirements. Clarify responsibilities before choosing a deployment model.
Sources and further reading
- Docker documentation — Docker
- Traefik documentation — Traefik Labs
- Let’s Encrypt documentation — Internet Security Research Group