Now an official Claude Certified PartnerLearn more
← InsightsEngineeringJune 3, 20262 min read

From monolith to headless: a real delivery story

The client had a content site on WordPress with seven years of plugin debt. Every new feature took weeks to ship. Here is how we moved it to headless without disrupting the editorial team.

The client published hundreds of articles a month. Their WordPress setup had been patched and extended for seven years. The frontend was slow, deployments involved twelve people, and any new feature meant going through an approval process just to get access to the hosting environment.

They wanted to move to headless. What they did not know was how to do it without breaking the editorial workflow their team used every day.

The constraint that shaped everything

The editorial team used Gutenberg blocks, custom fields, scheduled publishing, and contributor roles. All of that had to keep working exactly as it did. If the migration changed their daily workflow, the project would fail no matter how fast the new site loaded.

So we kept the WordPress admin completely intact. The REST API was extended where needed, not replaced. The React frontend read the same data structures the editorial team had always written to. From the content side, nothing changed on launch day.

Where the performance gains actually came from

The Lighthouse scores improved a lot by week six, but not because of React. The real gains came from moving image processing into the build pipeline, removing twelve third-party tracking scripts that had been added over the years, and prerendering the most visited routes to static HTML.

React made those things easier to do cleanly. But the decision to do them was the win, not the framework. A lot of headless migrations get sold on framework speed and delivered on plugin cleanup. Knowing the difference before you start saves a significant amount of time.

What took the most time

Redirects. The site had 341 URLs that had changed structure over seven years. Each one was a potential traffic loss if handled wrong. Auditing them, testing them, and staging the deployment took more calendar time than any other part of the project.

The site now publishes in a single pipeline step, loads in under two seconds on cold cache, and the editorial team noticed nothing different on launch day. That last part is what we were most focused on.

Want this working in your stack?

Trusted by teams at

ACAAutodeskDellHelloELLARevoolaElla Stein