If you're a head of digital or IT director at a mid-market law firm, I'm going to describe something and you can tell me if it sounds familiar.
You migrated your CMS about three years ago. The project went reasonably well - came in roughly on time, roughly on budget, and for the first 18 months or so, everyone was genuinely happy. The marketing team could publish without raising a ticket. The partners stopped complaining about their profile pages. The practice area sections finally made sense. You allowed yourself a quiet moment of satisfaction.
Then the firm opened a Scottish office. Or merged with a boutique employment practice. Or the SRA updated its transparency rules and suddenly you needed a new content type with an approval workflow that didn't exist. Someone in real estate wanted a dynamic deal tracker on their practice page. The regulatory team needed a way to flag outdated guidance. Three different partners asked why their thought leadership articles weren't showing up on their profiles automatically.
And now you're sitting in a meeting where someone, possibly you, is saying the words "we might need to look at the platform again."
I've been in that meeting more times than I can count. Not always at law firms, but disproportionately at law firms. And the thing that always strikes me is how often the people in the room assume the problem is that they chose the wrong platform last time. We just need a better platform this time. We'll make sure we choose something more scalable. That's the internal monologue. And it's understandable. But it's wrong - or at least, it's incomplete in a way that almost guarantees the pattern repeats.
Let me sketch this out, because once you see it, you can't unsee it.
Phase one: the firm starts on WordPress or something comparable. It handles the early requirements perfectly well. Five practice areas, a dozen lawyer profiles, a news section. Clean, simple, adequate.
Phase two: requirements grow. Plugins get added. Someone builds a custom integration with the practice management system. The theme gets modified so heavily it can't be updated without breaking something. A developer who left two years ago made architectural decisions that nobody fully understands but everyone depends on.
Phase three: the pain becomes acute enough to justify migration. A mid-tier CMS or DXP gets selected. The implementation is used as an opportunity to clean up the mess - rationalise content types, fix the taxonomy, build proper workflows. It works. For a while.
Phase four: 18 to 24 months in, the new requirements start arriving. A new practice area with sub-specialisms that don't fit the content model. A lateral hire who brings a team of six and needs profile pages by Friday. A regulatory change that requires a new approval workflow. The platform can technically accommodate these things, but each one requires developer time, and the queue for developer time is already three months long.
Phase five: you're back in the meeting.
The reason this keeps happening isn't that law firms are bad at choosing platforms. It's that the evaluation process each time is conducted against current requirements - what do we need the platform to do right now? - rather than against the rate at which those requirements are going to grow. And in law firms, that rate is faster than the CMS market's standard assumptions account for.
I'm generally sceptical of "our sector is special" arguments. Every sector thinks it's special. But having worked across professional services, financial services, SaaS, consulting, and legal, I do think law firms generate a specific pattern of platform stress that other B2B service firms don't - or at least, not to the same degree. Four things drive it.
Practice area complexity compounds in a way that's genuinely unusual. A 20-partner firm might have eight practice areas, each with sub-specialisms. That's not just eight sections on a website. It's eight distinct content taxonomies, eight sets of regulatory currency requirements, eight different internal audiences with different expectations about what "their" part of the site should look like. The content model that works beautifully for a three-section website becomes unwieldy at eight practice areas, because the relationships between content types - lawyers to practice areas, case studies to matter types, regulatory updates to relevant specialisms - compound with each addition. I worked with a firm last year where adding a single new practice area required changes to 14 different content type relationships. That's not a platform problem in the traditional sense. It's a structural complexity problem that most platforms aren't designed to absorb gracefully.
Multi-office and multi-jurisdictional requirements are a different beast from multi-location. A consulting firm with three UK offices might need different contact details and maybe some location-specific case studies. A law firm with offices in London, Birmingham, and Edinburgh has different regulatory frameworks, different court structures, different legal precedents that matter, and potentially different team structures serving different local markets. When you add an international associate network or a best-friends arrangement, the content management requirements multiply again. The platform that handles one content tree competently starts groaning when it needs to handle three or four, each with jurisdiction-specific variations.
Regulatory content demands are relentless. SRA guidance updates. Case law developments. Legislative amendments. Practice notes that need reviewing on a defined cycle. This isn't just "we publish a lot of content." It's content that is subject to specific currency requirements - content that can become actively harmful if it's outdated and a client relies on it. That requires a content governance workflow that most generic CMS platforms simply don't support natively. You end up building it through workarounds, and those workarounds are the first things that break when the platform is under stress.
Partners are demanding editors, and that's putting it politely. Individual partners want to publish thought leadership, control how their profile presents, and manage their practice area's positioning on the site. The CMS that can accommodate this across 20 partners - each with different technical confidence, different content production habits, and very strong opinions about how things should look - is a fundamentally different product from the one that worked fine when you had five partners who mostly left the website alone. I've sat with partners who can draft a 40-page commercial lease from memory but will abandon a CMS after three clicks if it's not immediately obvious how to upload a headshot. And honestly, I don't blame them. Their time is genuinely expensive and their patience for tool friction is - to put it diplomatically - limited.
So if evaluations keep focusing on current requirements rather than the trajectory of requirement growth, what should you be selecting for instead?
Start with editorial usability, because it's the criterion that gets treated as an afterthought and is probably the most important. A technically brilliant platform that frustrates fee earners will have low adoption. Low adoption means people find workarounds. Workarounds mean content lives outside the CMS - in email attachments, personal blogs, LinkedIn posts that should have been on the firm's website. Within six months, you've got a shadow content estate and a CMS that technically works but practically doesn't. I've seen this kill platforms that were, on paper, perfect for the firm. Any evaluation that doesn't include extended hands-on time with the people who'll actually be publishing - not just the IT team, not just the marketing manager, but actual partners and associates - is missing the factor most likely to determine whether you're back in that meeting in two years.
After that, the question is whether the platform has genuinely flexible content models. Not "we have lots of content types" - every CMS says that. I mean the ability to define custom content types with their own fields, relationships, and workflows without requiring a developer every time. Matter types. Lawyer profiles that dynamically pull in practice areas, publications, and case highlights. Regulatory guidance with defined review cycles. Court updates linked to relevant practice areas and jurisdictions. If creating a new content type for a new practice area requires a development sprint, you've already started the clock on the next migration.
Granular permissions and editorial workflows matter for similar reasons. The firm's actual content governance structure is complicated. Partner sign-off for thought leadership. PSL review for regulatory guidance. Marketing approval for website copy. Compliance review for anything client-facing. You need a platform where these workflows can be configured - and reconfigured as the firm evolves - without a developer building each one from scratch. A firm I spoke to recently had seven different approval workflows running through a combination of email chains and a shared spreadsheet because their CMS only supported a single publish/draft toggle. That's not unusual. It's also not sustainable.
Then there's integration architecture, which is where the hidden costs live. Your CMS doesn't exist in isolation. It needs to talk to your practice management system, your CRM, your client portal, your intranet, and increasingly your AI tools. If each of those connections requires bespoke development - rather than clean APIs that allow relatively straightforward integration - you'll spend more on maintaining connections than you did on the platform itself.
The evaluation question that breaks the pattern: not "can this platform handle our current requirements?" but "what will our requirements look like in five years, and can this platform handle those without the kind of customisation that would need rebuilding at the next migration?"
That means projecting - honestly, not optimistically - your likely growth in practice areas, office locations, partner headcount, and content volume over five years. Then assessing each shortlisted platform against the requirements that projection implies.
The platform that scores highest against your current requirements but lowest against your five-year projection is the platform that will produce the next migration. I know that's a counterintuitive way to frame it, but that's exactly the trap most evaluations fall into. They optimise for today's relief rather than tomorrow's resilience.
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.
If you're approaching your second or third CMS migration and getting a creeping sense of déjà vu, that feeling is diagnostic. It's telling you that the evaluation criteria you've been using aren't accounting for the specific pressures your firm puts on a platform.
You don't have to solve everything in one migration. But you do have to solve the right things, and specifically the structural factors that caused the last platform to run out of road.
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.