The Modernization Trap: Why Old Habits Build Old Systems

For years, publishing on our site worked the same way, and everyone had made their peace with it. The idea and the text for a new page could be ready in a day, yet they took weeks to reach a reader. The idea went from an author to a copywriter, to a designer, through review, to an engineer who finally built the page.

Every step looked perfectly reasonable on its own. What hurt was the number of handoffs between them. The designer was busy, the engineer was busy, and the idea sat on other people’s calendars, slowly going stale. How much we could publish depended less on how many good ideas we had than on how many people each idea had to pass through.

AI changed that math.

01 The Easy Part

We set out to remove the bottleneck, starting by escaping the WordPress CMS we had over-customized into a monster. Like any traditional CMS, it came with a data model of its own – pages and fields arranged on the vendor’s terms. Our process had grown around that shape rather than the work, and whenever the work didn’t fit, we added a workaround, making the process a little more complicated. That is what makes systems like this hard to leave: by the end, changing how we published meant untangling ourselves from someone else’s model first.

Content, design, and code moved into a single repository built on Astro, a modern web framework that is lightweight and flexible. Markdown became the main format – plain text with a bit of formatting, common enough by now that most people already write in it.

A simple article is a Markdown file. A page that needs a richer layout is assembled from our own components, and one that needs interactivity gets real code. Everything reaches production through a pull request, reviewed and previewed with the full history alongside.

But we were not simply replacing WordPress with a different technology stack. We were building an environment designed to be understood by both people and AI agents. The structure of a page, the available components, the brand rules, and the publishing checks all live alongside the content itself. An agent can see not only what to build, but also the constraints it has to build within.

That became the foundation of the new approach: the system should guide people and agents toward the right result, making it harder to break the site than to publish something that fits it.

The migration itself turned out to be the easy part. AI agents did most of the heavy lifting – reading the old site, porting the content into Markdown, and rebuilding pages against our new components – and a move we had postponed for years took far less time than it once would have.

And then we walked straight into the real trap.

02 The Trap of Our Own Experience

Many people in our publishing chain aren’t engineers, and we wanted to soften the transition for them. We started adding features to help: a preview first, then comments on a draft, then a way to move blocks around without touching code. Every request was fair, and we said yes to each one on its merits.

Two weeks later, we stopped and looked at what we had made. We had built a drag-and-drop page builder with commenting, one-click publish, and a separate tool for managing SEO. We had built a CMS.

The tool itself was fine, but we had gone in the wrong direction, one reasonable decision at a time.

Modernization looks like a systems problem, but it is actually a habits problem. The old system reassembles itself, because everyone pictures the work the same way: a system with an editor and a Publish button. That was the only picture any of us had, so protecting people meant handing them back the thing they already knew. Giving up the CMS meant giving up a piece of our own experience, and that was harder than any of the engineering.

We spent two weeks learning that, and it was worth more than everything else in the migration.

03 A New Formula for Work

Reinventing a process means designing it again from the result you actually need. We walked our old process and asked one question at every step:

Does this step improve the result, or does it only pass the work to the next person?

Most of them only passed the work along. We cut those, and the process that remained came down to one rule:

A person with an idea should be able to carry it through to the result themselves, with no unnecessary handoffs.

Now, technical people work on the site directly inside the repository using Claude Code. Everyone else uses Claude Cowork. They don’t need Git or terminal commands; they simply describe the result they need and get a finished page.

If anyone can build a page, who is responsible for quality? The same designers and engineers as before. But instead of checking every font and component by hand, they encode their expertise into the rules and skills the agents follow: how the brand should sound, where each component belongs, and what to use and when. These guardrails are part of the same infrastructure the agents work inside. They never start from a blank slate, and automated CI/CD checks catch the rest. Most mistakes are caught before anything is published.

The path from an idea to a published page takes less than two hours now.

04 Every Function Has Its Own CMS

The website is only one example on a much longer list, and not only in marketing.

Processes like this survive for one plain reason: rebuilding them never paid off. It took a dedicated team, months of work, a pile of integrations, and next to the day’s priorities, that investment was always the thing that got postponed. That is the math that changed.

We are running the same play in finance, HR, and sales. And every time, the same trap is waiting. In HR, the reflex is to buy a platform and pour people into someone else’s data model. In finance, the instinct is to rebuild the same chain of approvals, only faster.

Every function has its own “CMS” – a familiar, outdated shape it quietly recreates the moment someone starts modernizing.

“Rewrite the legacy” is a tech-debt line item that engineering owns, and it loses to feature development every time. “Modernize the process” is a business story a CTO can take to a CEO.

05 A Call to Process Owners

Start with one process you own. Follow a real piece of work from the initial request to the final result, noting every moment when it changes hands, waits for someone’s availability, or moves between systems.

Ask which steps genuinely improve the outcome, which exist only because of the tools you use, and which could become rules an AI agent can follow.

Do not ask only how AI can make the current process faster. Ask whether the person who needs the result could produce it directly, with the system carrying the expertise, constraints, and quality checks around them.

Do not begin with a better platform. Begin with a better path from intent to result.

The expensive thing may no longer be modernization. It may be continuing to work the old way.