WordPress vs Payload CMS: why we switched at Rovidx

We ran WordPress sites for years. By the time we started looking for a replacement, most of our front ends were already built with Next.js, with WordPress supplying content behind the scenes. That setup worked, but we wanted a CMS that fit the way our developers now build sites.

We chose Payload CMS after testing other options and building a custom CMS of our own. Here’s why we moved, where Payload has made our work easier, and where WordPress remains the simpler choice.

The short answer: which CMS is better?

For a standard marketing site that needs a quick launch and a familiar editing experience, WordPress is often the easier starting point. Hosting is widely available, and its themes and plugins cover many common needs without custom development.

For a team already building in Next.js, Payload can be a better fit. It runs within a Next.js application, gives developers control over the content model, and provides an admin panel and APIs for editors and front ends. You take on more responsibility for deployment, the database, and file storage. The right choice depends on the site and the team maintaining it.

Why we reconsidered WordPress

In September 2024, we were hosting our WordPress sites with WP Engine. We had already begun moving their front ends to Next.js while keeping WordPress as a headless CMS. That change reduced our costs and improved the visitor experience in our projects, but it also made us question whether the backend still fit our workflow.

That month, WordPress.org restricted WP Engine’s access to its resources during a dispute between the two organizations. Our sites did not suffer a major disruption. Still, the incident prompted us to look harder at our hosting costs and dependencies. We decided to evaluate other CMS options.

We tried several products. Some felt too restrictive for the sites we build. We also built a custom CMS, then set it aside because maintaining it would have put too much ongoing work on our team. After roughly a year of testing and iteration, we settled on Payload.

What changed when we moved to Payload

Payload works inside the Next.js stack we were already using. Our developers can define collections and fields in code, use the admin panel for content editing, and build the front end in the same JavaScript and React environment. That has made changes easier for our team to coordinate.

We also no longer need a WordPress theme or page builder for these sites. In our projects, that has reduced the subscriptions and infrastructure we were paying for. It does not mean Payload is automatically cheaper for everyone. Development time, hosting, database services, and maintenance still belong in the cost calculation.

Deployment took more work. Many hosts offer a one-click WordPress install. Payload needs an application deployment and a configured database, and media storage may need its own setup. We now use internal procedures and AI coding tools, including Codex and Claude Code, to help with those repeatable tasks. Our team still reviews the configuration and the result.

WordPress vs Payload CMS for a headless Next.js site

WordPress can absolutely power a headless site. Its REST API can send content to a separate Next.js front end, which is how we used it. If your editors are comfortable in WordPress and your content structure is fairly conventional, keeping that setup may be the practical choice.

Payload is worth considering when the website behaves more like a custom application, or when the development team wants the CMS schema and application code in one Next.js project. Its database adapters support PostgreSQL, MongoDB, and SQLite. That flexibility is useful, but it also means choosing and operating the right database for your deployment.

Can Payload replace WordPress?

For our sites, yes. We moved our publishing workflow and Next.js deployments to Payload. That does not make it a drop-in replacement for every WordPress site. A site that depends on a particular plugin, theme, or editor workflow may need custom work before it can move. Content migration, redirects, SEO metadata, forms, and media handling all deserve a plan.

Our decision came from the way Rovidx builds websites now. WordPress served us well, including as a headless CMS. Payload fits our current development process better, and it gives us more room to shape the content system around each project.

Further reading

WordPress REST API handbook

Payload installation and database adapters

Payload production deployment

WordPress.org statement on WP Engine access