Migrating Zero Gravity Marketing to Headless Next.js

A 150-page WordPress site running since 2012, a page builder added in 2017, and years of layers on top. Here's why the rebuild went headless instead of into another theme.

The site had been running since 2012. Twelve years is a long service life for a marketing site, and this one earned it. It carried the agency through several eras of the business. Around 2017, Beaver Builder was layered onto the custom theme so non-technical staff could build pages without waiting on a developer. That solved the problem in front of it. It also set the direction for everything added after.

By the time I got involved, the stack carried a lot of that history: a custom theme from 2012, a page builder holding years of accumulated layouts and shortcodes, and several caching layers added along the way to keep speed up as the site grew. Every piece made sense when it went in. Together they added up. Pages were slow to load, slow to open in the editor, and slow to build. A new page was closer to an afternoon of work than an hour.

Why I pushed for headless

I could have rebuilt it as a cleaner WordPress theme. That would have been faster to ship and easier to hand back. But performance wasn't really the main issue. The main issue was that the editing surface and the front end were the same surface. A copy change and a layout change sat one click apart. Routine content work could move something nobody intended to move, and tracing it back took longer than the edit itself. That's an architecture problem, not a people problem.

Headless separates the two. Editors work in their CMS, Sanity in this case, and the rendering layer stays in code. There's no template to modify by accident, because the editing surface doesn't reach it. For a marketing agency where several people touch the site every week, that separation isn't a nice-to-have.

The migration

150+ pages sounds like a lot to move. In practice, it came down to recognizing that most of the site was variations on the same 9 or 10 layouts: hero sections, team grids, service lists, case study pages, that kind of thing. I built those templates in Next.js and shifted content to fit rather than trying to preserve every pixel of every old layout.

For the blog, I built a custom migration tool to pull the existing posts out of WordPress and import them into Sanity. The tricky part was that the old posts weren't plain text. They had Beaver Builder blocks embedded throughout. FAQ sections, buttons, custom callouts, all mixed into the content. I wrote custom React components that matched the old Beaver Builder class names, so the migrated content would map directly to new components without having to manually rewrite every post. The class names became the contract between old and new.

I also had the agency's content team available to help rewrite or clean up copy where old pages didn't translate cleanly. On a migration this size, having that resource made a real difference.

How it ended

Page Speed Insights went from hovering around 40 to consistently above 90. That's the difference between a site that feels fast and one that doesn't, and for a marketing agency that sells web services, that number matters.

The bigger win is flexibility. Any layout or design request is now a component in code rather than a configuration exercise in a page builder. Requests that used to take hours, or weren't possible at all, are straightforward now. The content team publishes without having to think about the front end at all.

It was a larger build than a typical project. But the architecture decision was the right one, and the results backed it up. You can see the full project detail on the Zero Gravity Marketing project page.

If you're running a WordPress site that's showing its age, whether it's slow, hard to edit, or held together by a page builder you've outgrown, let's talk.