When a CMS becomes the bottleneck

Every CMS earns its place at some point. Someone picked it because it matched what the business
published back then: a handful of pages, a blog, maybe a product catalog with a dozen fields. The
choice was reasonable. The problem shows up years later, after the business has changed shape
several times and the CMS has been patched to follow, never redesigned to lead.

The signs are rarely dramatic. Nobody calls a meeting to announce that the content model has
failed. Instead, a marketing coordinator mentions, almost in passing, that she updates the team
page and the "who we are" section separately, because the CMS has no way to say that a person on
the team page is the same person quoted in a case study. Two records, two places to remember, two
chances to drift out of sync. That is not a training problem. That is a schema that was never built
to relate one type of content to another.

The friction that actually triggers a rebuild

"The CMS is old" rarely moves a budget. What moves it is someone tracing a delay back to its
source and finding the platform underneath it. A few patterns repeat across almost every migration
project:

A content type stops matching what the business sells. A services company that used to publish
one kind of page now runs three different sales motions, each needing its own fields, its own
relationships to case studies and pricing, its own approval flow. The CMS still has one generic
"page" type with a rich text field, so editors invent conventions: a bolded line means this, a
specific heading level means that. None of it is enforced. None of it is queryable. It works until
the person who invented the convention leaves.

A plugin graph turns into a liability. Each plugin solved a real problem when it was installed: a
form builder, a gallery, an SEO panel, a caching layer that only plays well with specific versions
of the others. Updating any one of them means checking whether it breaks the three that depend on
its old behavior. At some point nobody updates anything, and the site runs on a stack that stopped
receiving security patches two major versions ago, because the risk of updating now outweighs the
risk of standing still.

A simple content change needs a developer. This is the clearest tell. A client asks to change a
phone number in a footer, or reorder three items in a list, and the answer is "let me check with
the dev." Over years of patches, template logic and content ended up tangled in the same file:
conditional blocks that only make sense if you know the history of the site, hardcoded values
sitting next to fields that were supposed to replace them. The people who could safely touch that
code moved on, and everyone left is afraid to.

Page builders start working against the page. Drag-and-drop editors that felt liberating at launch
accumulate nested rows, columns and widgets that never get cleaned up, because removing a block
someone might still need feels riskier than leaving it. Every new page starts from a slightly
heavier baseline than the last. Load times creep up. The editor who just wants to publish a press
release has to wade through a builder interface that was designed for landing pages, not for a
three-paragraph announcement.

What a migration actually fixes

None of this gets solved by a theme change or a plugin cleanup. It gets solved by deciding, on
paper, what the business actually publishes now, not what it published when the CMS was chosen,
and building a content model around that reality: explicit relationships between content types
where the business needs them, fields that map to how editors already think about the content,
and templates that pull from that structure instead of encoding logic that only one developer
understands. Teams rebuilding around that principle often start with the same conversation used to
scope a full custom website build, because
the content model has to be settled before a single template gets written, not patched in after
launch.

The tell that a migration is overdue is not a design that looks dated. It is a team that has
learned to work around its own publishing tool: duplicate records, invented formatting
conventions, a backlog of "quick changes" that all need a developer, pages that get heavier every
quarter without anyone deciding they should. Those are architectural symptoms, not cosmetic ones,
and no amount of editorial discipline fixes a content model that was never built for what the
business does today.

Migrating is disruptive enough that most teams put it off until the workaround culture is fully
entrenched. By then the real cost is not the migration itself. It is every month spent maintaining
two versions of the truth because the old system never learned to relate them.

The team at Nooralto has walked several clients through exactly this kind of rebuild, from Agadir and from Paris.