An agency does not operate a content management system once. It repeats the same activities across a portfolio: create a client site, grant access, ship changes, update dependencies, respond to failures and eventually hand the project over. The cost of a small friction point multiplies across that portfolio.
A good CMS evaluation therefore starts with workflows, not a feature checklist. Ask three people to perform representative tasks: a client editor changes a page, a developer updates an extension, and an account manager prepares a handoff. Record the steps, permissions and help each person needs.
First, draw the ownership map
For every project, record who owns the domain, hosting account, CMS licence, source files, media and external service connections. Identify who renews each service and who can recover access. Store passwords and tokens in an appropriate password manager, not in the handoff spreadsheet.
A portfolio of separate installations is not automatically a centrally managed multi-site system. Check how the candidate product creates projects, stores data and applies updates. If it lacks a shared dashboard, consider whether your team's existing inventory and maintenance process can handle that safely.
Also ask what is isolated between clients. Separate domain names alone do not prove separation of databases, files, credentials or background jobs. The right deployment model depends on your clients, operational skills and recovery requirements.
Test permissions with actual accounts
Role names are not enough. A role called “editor” might be able to do more or less than your client expects. Build a small acceptance matrix:
| Participant | Typical task | Boundary to test |
|---|---|---|
| Client editor | Update text and images | No unnecessary access to users or extensions |
| Agency content manager | Prepare and review pages | Access only to assigned projects |
| Developer | Maintain themes and integrations | Changes follow the agreed release process |
| Site administrator | Manage access and backups | Ownership and recovery responsibility are documented |
Create individual test accounts. Try the allowed task and attempt a sensitive action that should be blocked. Check whether the installation supports the level of audit history and login protection you need; do not assume every deployment has the same controls.
Make client editing a handoff test
Invite a person who has not built the site to find a page, change a heading, replace an image and check the result. Can they recover from a mistake? Do they know when a change is public and whom to contact if a form stops working?
Agree which changes are self-service and which need review. Updating a news item may be a normal editorial task; changing a payment integration may require a developer and a test plan. Document the boundary rather than relying on a shared administrator password.
Design updates around recovery
Inventory the CMS core, theme, extensions, runtime and external services. Check compatibility before applying changes. For a meaningful update, a practical sequence is:
- Record the versions and identify the project owner.
- Create a backup and confirm whether external media is included.
- Test on a separate copy where feasible, using safe test data.
- Exercise important flows: editor login, key pages, forms, catalogues and integrations.
- Release during an agreed window and repeat the critical checks.
Agree on a stop condition and a recovery route before making changes, especially when database migrations or external systems are involved. An archive is useful only if the team understands its contents and has tested how to restore it. Periodic restoration drills on a separate environment expose gaps that a successful backup job alone can miss.
Calculate portfolio cost
Compare candidates across the same projects and period. Include licences, hosting, storage, support, training, extension maintenance and developer time. Ask what a hosted plan includes and who is responsible for backups, monitoring and upgrades. For self-hosted deployments, account for the server work as well as the CMS itself.
For illustration, twelve client sites with two hours of planned checks each quarter require 24 hours per quarter before incidents, communications or unusually complex integrations. That is an assumption for planning, not an industry benchmark. Replace it with your own measurements and add renewal and handoff costs.
Run a small, representative pilot
Choose one content-heavy client site and one project with an essential integration. Give each candidate the same brief:
- An editor makes a routine change using a personal account.
- A developer connects the required service and tests an error case.
- The team records a backup and demonstrates a recovery plan.
- One component is updated and the agreed acceptance checks are repeated.
- A second person prepares the domain, licence, dependency and documentation handoff.
Score the outcome for access control, maintainability, portability, support and total effort. Keep hard requirements visible: a pleasant editor does not compensate for a project you cannot safely recover or transfer.
The original Russian-language article is available on Morlix.
Top comments (0)