A law firm can replace its CMS and meet the same constraint again because the migration fixed today's visible pain without changing how future content, workflows and integrations are governed.

The platform may genuinely be unsuitable. It may also be carrying the consequences of uncontrolled customisation, unclear ownership, a long development queue or a content model that mirrors one moment in the firm's structure.

Before another selection, establish which limit belongs to the product, implementation, operating model or organisation.

Growth changes relationships, not only volume

A new office, practice, jurisdiction or lateral team adds more than pages. It can change relationships among people, services, sectors, cases, locations, languages, credentials and legal guidance.

A content model built around one tree can become difficult when the same lawyer belongs to several practices and locations, or when an article needs jurisdiction, topic, audience, author and review status.

This is structured information design. Adding a new content type for every exception can make the model harder to understand and maintain. Forcing every exception into generic pages creates other problems.

Model representative future scenarios before procurement. Ask which relationships are stable concepts and which are temporary presentation needs.

Regulatory and professional content needs lifecycle control

Legal content can become wrong or unsafe as law, guidance and the firm's services change.

The CMS should support ownership, review date, status, evidence and an appropriate approval route. Notifications alone are insufficient if nobody has capacity or authority to act. Expiry can also be risky if a page disappears without redirect or archive decision.

Different content carries different risk. A durable expert opinion, current legal update, lawyer profile and regulatory disclosure may need different workflows and review intervals.

Requirements should come from current Legal, Risk and professional obligations. Do not assume one sector-wide workflow or preserve old claims about a regulator's rules without checking authoritative material at implementation.

Editorial autonomy needs safe boundaries

Partners and associates should be able to contribute without turning every request into developer work. They do not all need unrestricted ability to alter the content model or visual system.

Define roles around real tasks. A subject expert may draft and review legal accuracy. Marketing may own structure and publication. A practice lead may approve position. Compliance may enter for specific triggers. Platform administrators manage configuration and access.

Test with people of differing confidence and access needs. Observe them creating, finding, updating, reviewing and withdrawing content. A product demo led by the implementation team cannot show normal editorial effort.

The best interface is the one configured for the firm's common work and exceptions, supported by guidance and ownership.

“No developer required” is not always the target

Code-free schema and workflow changes can improve responsiveness. They can also allow the information architecture to fragment, permissions to weaken and integrations to break.

Decide which changes editors can make safely, which require platform administration and which need engineering review. Provide a service level for normal requests.

A three-month developer queue is an operating-model failure even if the platform technically supports the change. Measure demand, capacity and causes before concluding that replacement is required.

Integration creates lifecycle cost

The CMS may connect with CRM, practice management, identity, email, search, client services, analytics and other publishing channels.

For each connection, define the source of record, data purpose, access, matching, update direction, errors, monitoring and ownership. Reuse official APIs where suitable and examine their limits. Custom code is sometimes necessary and should have tests, documentation and an upgrade plan.

Do not connect systems because a future AI tool might use the data. Start with a service or decision, apply privacy and confidentiality boundaries, and create reliable interfaces only where value justifies them.

A new CMS cannot repair underlying client or matter data by receiving it faster.

Platform age is weak evidence

A three-year-old platform can be poorly operated. A much older one can remain safe and useful with supported software, good architecture and capable ownership.

Assess:

  • vendor and component support;
  • security and patching;
  • accessibility;
  • performance and resilience;
  • editorial task success;
  • change lead time;
  • integration reliability;
  • content quality and lifecycle;
  • licence and operating cost;
  • skills and supplier availability;
  • exit and data portability.

Collect evidence across representative templates and journeys. Avoid letting one senior frustration or one impressive new product determine the conclusion.

Forecast capabilities, then preserve options

A five-year requirements list creates false certainty. Project plausible changes and evaluate how the service would respond.

Scenarios might include a merger, another jurisdiction, a major rebrand, a new regulatory workflow, a change of CRM, multilingual publishing, a large lateral team or a new client-content product.

For each, ask:

  • Which content and permissions change?
  • Can the current model extend without duplication?
  • What requires configuration, code or migration?
  • Which integration and data assumptions fail?
  • How long would a competent team need?
  • What would become irreversible?
  • Which option preserves a credible exit?

This tests adaptability without pretending to know the exact firm in five years.

Content model flexibility needs constraints

Look for typed relationships, reusable components, validation, versioning, preview, scheduling, search and APIs appropriate to the service. Product capability should be checked against current documentation and a working prototype.

A theoretically flexible platform can be implemented rigidly. Ask the delivery partner to add a representative practice or workflow during evaluation and show the effect on existing content.

Inspect migration and version control for schema changes. An administration screen that lets somebody add fields instantly may hide downstream code and search work.

Permissions and workflow need real exceptions

Model who can view, draft, edit, approve, publish and administer across practice, jurisdiction and content type.

Then test absence, urgent correction, conflicting reviewers, a departed partner and a disclosure due to change on a fixed date. Workflows that only handle the successful standard route tend to move exceptions into email.

Keep audit records proportionate and protect sensitive drafts. Avoid giving broad access because granular configuration takes longer.

Select the operating model with the platform

A CMS decision includes internal owner, editor support, development, hosting, security, accessibility, monitoring, upgrade and supplier responsibilities.

Estimate three-to-five-year cost using the firm's likely change, and show uncertainty. Include content migration, integration, testing, training, maintenance and eventual exit.

Choose whether capability will sit internally, with one retained partner or across suppliers. Concentration can be reasonable when service and exit are clear.

The platform limitations I've described here have a direct knock-on effect on client experience too. There's a companion piece on what a strong digital experience actually looks like for Top 100 law firms - it's worth reading alongside this, because the platform problems I've outlined are often the root cause of the experience gaps that piece measures.

Decide repair, reconfigure or replace

Repair when defects and support issues can be corrected without changing the core model.

Reconfigure when the platform can support the intended workflows and architecture but the current implementation does not.

Replace when material requirements conflict with product limits, support or sustainable cost and alternative treatment is weaker.

Retire or simplify content and integrations that no longer serve a current need.

Compare options and their transition risk. Replacement should not be the default reward for accumulated neglect.

Break the cycle through governance

After launch, maintain a content-model owner, technical owner and editorial service. Review proposed components and fields, monitor workarounds, remove unused structures and test priority journeys after updates.

Keep a decision record so future teams know why a relationship or workflow exists. Budget for change. A CMS designed to evolve still requires people to evolve it.

If you want to assess how your current CMS maps against the longevity criteria for law firms - and understand what platform decisions would actually break the replacement cycle rather than restart it - book a platform review. We've also put together a law firm CMS longevity checklist: a one-page assessment covering flexible content models, permissions and workflow, integration architecture, and editorial usability, with legal-specific indicators for each and a five-year requirements projection exercise. It's free, it takes about twenty minutes, and it'll tell you whether you're heading for another meeting you'd rather not have.