WordPress is not a bad choice, but it grows against you
WordPress powers forty percent of the web for a reason. It is flexible, the community is large, and for a modest budget you get a working site quickly. But that flexibility has a price: everything is built on plugins, themes and a database that were not designed to work together.
At first you do not notice. You install a contact form plugin, an SEO plugin, a caching plugin, a backup plugin. Fine. But once your site grows and you add more functionality, activate more plugins and customise more themes, you end up with a web of dependencies that nobody fully understands. Including yourself.
I call it WordPress spaghetti. Not as a criticism of the tool, but as a description of a pattern I see repeatedly in SME sites that are five years old: twenty, thirty, sometimes eighty plugins. Themes customised by three different developers. An update schedule nobody maintains because updating breaks the site.
What goes wrong with WordPress at scale
The problems I encounter most often in WordPress sites that have grown too large:
- ▸Plugin conflicts: two plugins requiring the same jQuery version that then clash. A WooCommerce update that breaks the checkout page. An Elementor update that overwrites custom CSS.
- ▸Security vulnerabilities: WordPress is the most attacked CMS in the world. Every outdated plugin is a potential attack vector. I regularly encounter sites that are three versions behind on critical patches.
- ▸Performance problems: Elementor and Divi load megabytes of CSS and JavaScript for every page, even if you only used the builder for the homepage. An LCP of four seconds is not an exception. It is the norm.
- ▸Licence costs that add up: premium plugins cost €50–€300 per year, per plugin. A site with ten premium plugins pays more in annual licences than in hosting.
- ▸Developer scarcity: there are plenty of WordPress developers, but a good developer who also understands how performance, security and custom post types relate is scarce and expensive.
- ▸Lock-in through page builders: a site built in Elementor or Beaver Builder is practically non-transferable to a different approach without rebuilding everything.
This is not theory. These are the findings I encounter in the audit I always carry out before starting a migration. Most clients are surprised by the scope, not by its existence.
How I migrate your content and URLs
The technical core of a WordPress migration is the content export and the redirect mapping. WordPress has a REST API that I use to export all posts, pages, custom post types, media and taxonomies in a structured way. That gives me a JSON dump that I can then transform into MDX files or a headless CMS.
Alongside the content I build a complete URL map. I crawl your existing site, compare it with your Google Search Console data, and build a redirect table that links every indexed URL to the new URL structure. That table is implemented as 301 redirect by 301 redirect before the new site goes live.
- ▸WP REST API export: all posts, pages, custom post types and media are exported via the standard WordPress REST endpoints. No manual copying.
- ▸Content transformation: the raw WordPress HTML is converted to clean MDX or CMS input, without shortcodes, without Elementor markup, without hidden styles.
- ▸Redirect mapping: every URL indexed in Google gets a 301 redirect to the equivalent new URL. Including page-2 variants and category URLs.
- ▸Sitemap submission: after going live I submit the new sitemap.xml to Google Search Console and monitor the crawl statistics.
Security: the silent risk of an outdated WordPress site
WordPress security is an active effort, not a one-time setting. Every day new vulnerabilities are discovered in plugins and themes. If you do not update a plugin because you are afraid the site will break, you leave the door open for automated attacks that scan WordPress installations en masse for known vulnerabilities.
I have had clients who discovered their WordPress site had been part of a spam network for months. The site worked fine, but the server was sending thousands of spam emails per day. In another case a redirect had been injected that sent mobile visitors to a phishing page. Both incidents were the result of an unpatched plugin.
Next.js does not have this problem structurally. There is no database that can be queried directly via SQL injection. There is no plugin architecture with back doors. The attack surface is minimal: static files, an API endpoint if needed, and a managed hosting environment. After the migration you no longer need to check daily whether a plugin update is waiting that could break your site.
-- Client case
From 83 plugins and 4.2s LCP to Lighthouse 100 and 12 dependencies
A healthcare practice in Overijssel with three treatment locations was running on a WordPress site that had grown over eight years to 83 active plugins, an Elementor theme with hundreds of custom CSS rules and a WooCommerce installation for booking online appointments. The site was technically operational, but performed poorly: LCP at 4.2 seconds, Lighthouse Performance between 28 and 35, and dozens of crawl errors visible in Google Search Console.
At the intake the following measurements appeared:
The new site runs on Next.js with an own CMS as the CMS for staff pages and blog posts. WooCommerce was replaced with an integration with the practice's own appointment system via a lightweight API connection. The number of dependencies was reduced from 83 plugins to 12 npm packages. The practice manager now manages content independently via an own CMS, without access to the WordPress admin or the risk of plugin conflicts.
What I do differently from a WordPress agency
Most WordPress agencies solve a WordPress problem with a WordPress solution: a better caching plugin, a different theme, more server memory. That works in the short term, but it does not solve the structural problem. Plugins are not the problem. The system of dependencies is the problem.
I do not use WordPress as my output. I use WordPress as a starting point: I read your data via the REST API, export your content, and build a new environment in Next.js that carries none of the WordPress assumptions. No database vulnerable to SQL injection. No plugin updates that can break the site. No monthly licences for form plugins.
What I bring along: your content, your URLs, your SEO position and your design intent. What I leave behind: the technical debt, the plugin chaos and the security risks. The result is a site you fully understand, that I can maintain, and that does not depend on the roadmap of a third-party plugin developer.
Admin and CMS after the migration
A common concern: 'But I want to be able to update my own content.' You can. And better than in WordPress. Depending on the amount of content and how often you update it, I choose from:
- ▸an own CMS: a Git-based CMS that writes directly to the repository. No separate database, no separate server. You edit content in a clear UI, I see the change as a Git commit.
- ▸an own CMS: a headless CMS with a fully configurable editorial interface. Suitable if you have multiple editors or if the content structure is complex.
- ▸MDX files: for simple sites with infrequent content updates, a direct MDX structure works too. You edit Markdown files, I deploy automatically via a CI/CD pipeline.
- ▸No CMS: for brochure sites where content rarely changes, a CMS is unnecessary. I deliver the pages as static files and you contact me when something needs to change.
In all cases you have full access to your own data. There is no WordPress admin requiring a separate password, no database that needs separate security, and no plugin that stores your content in a proprietary format that is hard to export.
What does this cost?
Every project is different. The price depends on your site, scope and what is needed. No rate without first understanding what you need.
Book a short call. I look at your situation and give you an honest proposal.