Requests to "get off WordPress" usually start with a concrete complaint: weekly plugin update notices, a slow site, a dashboard staff avoid, a security warning email.
But the cause is not always WordPress itself. If the problem is an old theme, too many plugins or outdated PHP, rebuilding on WordPress can be cheaper, faster and safer. If the way you use the site has drifted away from what WordPress does well, moving can make day-to-day operation lighter.
This article first checks, with primary-source figures, how widely WordPress is used and what maintenance burden it carries, then sets out the criteria for staying or moving and the steps if you move. Redirects for changed URLs are covered in detail in "Website Redesign Without Losing Rankings: A 301 Redirect Plan", and how to read a full quote in "Website Redesign Cost and How to Read a Quote".
Main sources for this article
- W3Techs, "Usage statistics of content management systems" (as of 24 October 2026)
- WordPress.org usage statistics (PHP and WordPress version distribution, retrieved 24 October 2026) and official documentation (export, REST API, requirements)
- HTTP Archive, "Web Almanac 2025", CMS chapter (published January 2026)
- PHP's supported versions table and Patchstack's "State of WordPress Security in 2026"
- Google Search Central guidance on site moves, hreflang and JavaScript SEO; the European Accessibility Act (Directive (EU) 2019/882)
| What this article covers | Short answer |
|---|---|
| How widely is WordPress used? | 39.6% of all sites, 58.3% of CMS sites (section 1) |
| Where is the maintenance burden? | Old PHP versions and plugin vulnerabilities (section 2) |
| What alternatives exist? | Static site generator, headless CMS, SaaS builder, custom CMS (section 3) |
| How do I decide? | Two axes: update frequency/editors, and feature load (sections 4–5) |
| Where does a migration start? | Inventory and mapping, then export (sections 6–9) |
| Multilingual content and launch? | Translation map, unchanged URLs, rollback plan (sections 10–11) |
1. How widely is WordPress used today?
About 40% of all sites, about 60% of CMS sites
According to W3Techs, which tracks web technologies, as of 24 October 2026 WordPress is used by 39.6% of all websites, and among sites that use a CMS (content management system) its share is 58.3%. Shopify, in second place, is used by 5.3% of all sites.
The table lists the leading figures. "No CMS" means sites using none of the systems W3Techs detects, such as hand-written HTML or in-house builds.
| System | Share of all websites | Share of CMS sites |
|---|---|---|
| WordPress | 39.6% | 58.3% |
| Shopify | 5.3% | — |
| Wix | 4.2% | — |
| Squarespace | 2.4% | — |
| Joomla | 1.1% | — |
| No CMS (not detected) | 32.1% | — |
WordPress is clearly not a niche legacy system, and more agencies, developers and documentation exist for it than for any alternative. Moving means giving up this pool of people and information too.
Crawl data agrees: over 60% of CMS sites run WordPress
W3Techs surveys the top 10 million sites. HTTP Archive's "Web Almanac 2025", which crawls a much wider set of sites, found that CMS-driven sites make up over 54% of observed websites, and that about 64.3% of them on mobile run WordPress. Shopify is at about 7.3%, Wix about 5.2% and Squarespace about 3%.
The methods differ, so the numbers do not match, but the conclusion is the same.
The official WordPress.org plugin directory lists 72,476 plugins as of 24 October 2026 (the result count from the WordPress.org plugin search API). The latest core release is the 7.1 branch, and WordPress.org statistics show 63.7% of active sites on 7.1. This "add anything with a plugin" model is both its greatest strength and the source of its maintenance burden.
2. Why migrations get considered: the maintenance burden in numbers
A third of sites run on unsupported PHP
WordPress runs on PHP. Each PHP version gets two years of active support, then two years of security fixes only, after which vulnerabilities are no longer fixed.
The table puts PHP's official support dates next to the PHP version distribution from WordPress.org statistics. WordPress.org recommends PHP 8.3 or greater.
| PHP version | Security support ends | Share of WordPress sites |
|---|---|---|
| 7.4 or older | Ended (7.4: 28 Nov 2022) | 20.8% |
| 8.0 | Ended (26 Nov 2023) | 3.6% |
| 8.1 | Ended (31 Dec 2025) | 9.8% |
| 8.2 | 31 Dec 2026 | 23.3% |
| 8.3 | 31 Dec 2027 | 27.2% |
| 8.4 | 31 Dec 2028 | 10.0% |
| 8.5 | 31 Dec 2029 | 5.3% |
In total, about 34% of WordPress sites run on PHP 8.1 or older, with no security fixes. PHP 8.2, used by another 23% or so, loses fixes on 31 December 2026, after which more than half of WordPress sites will be on unsupported PHP.
However, old PHP is not in itself a reason to leave WordPress. Most hosts let you switch PHP in their control panel. The problem comes when old plugins or themes do not run on newer PHP; rebuilding them can be as much work as a migration.
Nine in ten vulnerabilities come from plugins
Security company Patchstack reports 11,334 new vulnerabilities in the WordPress ecosystem in 2025, up 42% from 7,966. 91% were in plugins and 9% in themes; core had six, all low priority. 46% had no developer fix at disclosure.
Patchstack sells vulnerability protection and counts the reports it collects, but the pattern is clear: risk scales with the number and quality of plugins and themes, not with core.
Measure the burden on your own site
Counting four things on your own site is more useful than general statistics. Each takes about 30 minutes.
| What to measure | Where to look | When to consider moving |
|---|---|---|
| Number of active plugins | Plugins screen in the dashboard | Over 20, some with no known purpose |
| Plugins not updated in 2+ years | Each plugin's WordPress.org page | Even one carries a core feature |
| PHP version | Tools → Site Health | 8.2 or lower, and parts break on upgrade |
| Maintenance time in the last 12 months | Work logs, invoices | More maintenance jobs than content updates |
The thresholds are based on DevNJ's experience, not an official standard. If two or more apply, the comparison below is worth your time.
3. Four alternatives, plus "rebuild on WordPress"
Five options side by side
Destinations fall into four broad types. Adding rebuilding on WordPress gives five options. They are described by type rather than product, because choosing the type first makes picking a product easier.
| Option | How it works | Suits sites that | Main weakness |
|---|---|---|---|
| Rebuild on WordPress | New theme, fewer plugins | Have many editors, lots of posts | Maintenance remains |
| Static site generator | HTML built in advance from source | Change rarely, need speed | Hard for non-technical editors |
| Headless CMS | Editing and display separated | Publish to several channels | Two systems to run |
| SaaS website builder | Built on a provider's service | Staff want to edit themselves | Limits on export and freedom |
| Custom framework-built CMS | Only the features you need | Are tied to business systems | Dependence on developers |
None of these weaknesses is fatal. What matters is whether your organisation can absorb it.
Static site generator
A static site generator (SSG) combines source text, often Markdown, with templates and builds every page as HTML before publishing. With no database read per visit, pages are fast and there are fewer entry points for attackers.
But forms, site search, member accounts and anything else that needs request-time processing must be handled by an external service or a separate program. Updates often go through Git, so an SSG does not suit sites that non-technical staff update daily.
Headless CMS
A headless CMS provides only the editing interface; the display layer is built separately, pulling content through an API for a website, an app or other screens. WordPress has a REST API, so you can also keep WordPress for editing and rebuild only the front end.
The catch is that you run two systems. Without a good preview, editors cannot see content before publishing. If the front end uses JavaScript, follow Google's JavaScript SEO guidance so search engines can read the content.
SaaS website builder
A SaaS builder lets you assemble a site visually on a provider's service, which handles servers, updates and security. It is most effective when you want to hand maintenance out of the organisation.
In exchange, you can only build what the service supports. URL structure, multilingual handling and export vary by product, and some do not allow bulk export if you move again. Check export before signing up.
Custom framework-built CMS
This means developing an admin interface with only the features you need on a framework such as Laravel, Django or Next.js. For sites tied to bookings, stock or customer records, it is often clearer than combining plugins.
But because it depends heavily on whoever built it, putting design documents, the data model and runbooks into the contract is a precondition.
4. Criteria for staying or moving
Two axes
The decision rests on two axes: who updates the site and how often, and how many features and integrations it carries. Together they form four rough quadrants.
The quadrants are only a starting point. The top right is where WordPress is strongest; moving away there can mean building more, not less.
Eight questions
When the two axes are not enough, answering the following eight questions narrows the options.
| Question | Answer that favours WordPress | Answer that favours moving |
|---|---|---|
| Who updates the site? | Several non-technical staff | One or two people, or developers |
| How often? | Weekly or more | Monthly or less |
| What features are needed? | Posts, forms, search | Bookings, members, integrations |
| How many plugins? | Around 10, each with a clear role | Over 20, some unexplained |
| Multilingual? | None or up to two languages | Three or more, same structure |
| Who maintains it? | A contracted maintenance provider | Nobody |
| Plans for three years out? | More content in the same form | Major changes to business or features |
| In-house skills? | Staff familiar with WordPress | Developers skilled in another stack |
If the answers split evenly, it is safer not to rush. Pruning plugins, upgrading PHP and agreeing a maintenance contract often solve much of the problem.
5. Do speed and quality depend on the CMS?
Core Web Vitals pass rates differ by CMS
Let us check WordPress's reputation for slowness against data. Google's Core Web Vitals treat a page as "good" when LCP (time until the largest element appears) is 2.5 seconds or less, INP (response to interaction) is 200 milliseconds or less, and CLS (layout shift) is 0.1 or less.
The Web Almanac publishes pass rates by CMS from Chrome UX Report real-user data. The table compares 2024 and 2025 mobile figures.
| CMS | 2024 (mobile) | 2025 (mobile) |
|---|---|---|
| Duda | 73% | 85% |
| Wix | 57% | 74% |
| Squarespace | 60% | Up (rate not stated) |
| Drupal | 56% | Up (rate not stated) |
| Joomla | 45% | Up (rate not stated) |
| WordPress | 40% | 45% |
WordPress's 2025 pass rate was 45%, lower than SaaS builders Wix (74%) and Duda (85%).
Most of the gap comes from how sites are built
Reading this as "WordPress is slow" would be premature. WordPress sites vary enormously, and old themes and heavy page builders pull the average down, while SaaS providers optimise image delivery and the like for every site.
A well-built WordPress site is fast enough, and a carelessly built replacement will be slow. If speed is your reason to move, first check PageSpeed Insights to find whether images, scripts or the server are the cause. Theme or plugin problems can be fixed on WordPress.
6. The migration at a glance: six stages and timings
Export is stage three
It is tempting to start exporting straight away, but export is stage three. Until you know what moves and in what shape, you will keep reprocessing data.
| Stage | What happens | Output |
|---|---|---|
| 1. Inventory | Count pages, post types, plugins and forms | Inventory sheet |
| 2. Mapping and design | Match old fields to new ones | Data mapping table, URL policy |
| 3. Export and convert | Extract and convert WXR, media, form data | Conversion scripts and results |
| 4. Replace features | Move plugin functions to the new system | Replacement table and build |
| 5. Verify and freeze | Compare old and new, stop edits | Test results, freeze notice |
| 6. Launch and monitor | Switch DNS, redirects, monitoring | Launch runbook, monitoring log |
In migrations that go well, stages 1 and 2 take 30 to 40% of the time. Cutting them short means rework later.
7. Inventory and export: content, media, users and forms
Count first: building the inventory sheet
The inventory counts what is inside WordPress by type and decides whether each item moves, is merged or is dropped, including drafts, private items and attachment pages.
| What to count | Where to check | What to decide |
|---|---|---|
| Posts and pages | Dashboard lists, by status | Move, merge or delete |
| Custom post types | Dashboard menu, theme code | Their type in the new system |
| Categories and tags | Dashboard lists | Which to keep or merge |
| Images and attachments | Media Library, uploads folder | What to do with unused files |
| Users | Users list, by role | Who moves and who does not |
| Forms and submissions | Form plugins | Retention and scope |
| Shortcodes and blocks | Search the body text | How to replace them |
Clean up pages with no traffic and outdated content now; less to move means less testing. Record deleted URLs as redirect candidates.
Content: what WXR includes and what it does not
Tools → Export produces an XML file in WXR (WordPress eXtended RSS) format. Per the official documentation, it covers posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies and users, and choosing "All content" also includes navigation menus. The WP-CLI command wp export produces the same format from the command line.
| Item | In WXR? | How to get it if not |
|---|---|---|
| Body, title, date, URL slug | Yes | — |
| Categories, tags, custom taxonomies | Yes | — |
| Custom fields | Yes | Check complex nested data |
| The image files themselves | No (URLs only) | Copy the uploads folder |
| User passwords | No | Extract from the database |
| Theme and plugin settings | No | Record screens, rebuild |
| Form submissions | Usually not | Each plugin's CSV export |
| SEO settings (titles, descriptions) | Depends on the plugin | Check as custom fields |
WXR is designed for WordPress-to-WordPress moves, and other systems often cannot read it. The usual approach is a script that converts it to an intermediate format such as JSON or Markdown, or pulling only the fields you need from the REST API, for example posts from /wp-json/wp/v2/posts.
Watch for WordPress-specific pieces left in the body
Block editor posts carry comments such as <!-- wp:paragraph -->, and shortcodes (square-bracket elements such as [gallery]) appear as raw text outside WordPress.
Search all body text for shortcodes, count each type and decide how to convert it: frequent ones by script, rare ones by hand.
Media: move both the files and the URLs
Copy the wp-content/uploads folder in full. WordPress generates several sizes per image, so move only the originals and let the new system generate sizes. Replace body image URLs (/wp-content/uploads/...) with new locations.
Users: passwords and personal data
Moving users needs the most care. WXR includes names and email addresses but not passwords, which must come from the database in a format that depends on the WordPress version.
| WordPress version | Password storage format | Handling in the new system |
|---|---|---|
| 6.7 and earlier | phpass (starts with $P$) |
Implement compatible checks, or reset |
| 6.8 and later | bcrypt-based (starts with $wp$2y$) |
Same; rehashed as users log in |
| Either | Application passwords use another format | Do not move; have them reissued |
From 6.8, phpass hashes are replaced as each user logs in. If the new system cannot verify either format, have users reset their password on first login, and tell them in advance.
User data is personal data. Both the EU GDPR and Japan's Act on the Protection of Personal Information (APPI) require appropriate contracts and disclosure when entrusting it to a new service (see section 15). WordPress's Tools → Export Personal Data also helps if someone requests their data before the move.
Forms: move submissions or delete them?
Form plugins store submissions in their own tables or as posts, so they are usually not in WXR. Each plugin's CSV export gets them out, but first ask whether they need to move at all. If the history lives in email or a CRM, set a retention period and delete it instead, in line with the GDPR principle of not keeping data longer than necessary.
8. Building the data mapping table
The mapping table is the blueprint
A data mapping table lists which field in the new system each WordPress item becomes. Without one, you lose track of where information went.
| WordPress item | Example | Field in the new system | Note |
|---|---|---|---|
| Post | Blog article | Article type | Move both published and modified dates |
| Page | About us | Page type | Reflect parent/child in URLs |
| Custom post type | Case studies | Dedicated type | Design fields per type |
| Custom field | Price, location | Field on the type | Normalise formats (number, date) |
| Categories and tags | News | Taxonomy | Decide which to merge |
| Featured image | Post thumbnail | Image field | Move alt text too |
| Author | Writer | Author type | Decide how to handle ex-staff |
| Revisions | Edit history | Usually not moved | Export and archive if needed |
Put the URL policy in the mapping table
Include columns for old URL and new URL as well. WordPress URLs are set in Permalink Settings and may contain dates (/2023/05/slug/) or categories (/category/slug/).
The safest option is not to change a single URL. Google treats this as a "site move with no URL changes", a much lighter process. Check whether each destination lets you set URL structure freely. For the steps when URLs do change, see "Website Redesign Without Losing Rankings: A 301 Redirect Plan".
Do not drop SEO data
SEO plugins often store search titles, descriptions and noindex flags in custom fields, and they vanish unless the mapping table names them. Add columns for "search title", "description", "canonical", "noindex" and "OGP image", and compare with the old site during testing.
9. Replacing plugin features
Translate plugins into features
The same components will not exist in the new system, so first write down in words what each plugin does: not "SEO plugin" but "search title settings, XML sitemap, breadcrumb structured data".
| Common feature | In WordPress | Example replacement |
|---|---|---|
| Search titles, sitemap | SEO plugin | Template fields and auto-generation |
| Contact forms | Form plugin | External form service or own handler |
| Speed | Caching plugin | Static delivery and a CDN |
| Login protection | Security plugin | Separate admin, two-factor auth |
| Multilingual | Multilingual plugin | Per-language fields and links |
| Redirects | Redirect plugin | Server or CDN configuration |
| Cookie consent | Consent plugin | Choose a consent tool again |
| Backups | Backup plugin | Hosting backups and Git history |
Find features to drop rather than replace
This reveals features the new system no longer needs: with an SSG or SaaS builder, caching and security are handled by the platform.
Conversely, some features, such as scheduled publishing, per-editor permissions, preview before publishing and site search, must be newly built in the destination.
The editing experience is part of the replacement
Most often overlooked is the editors' experience. Before migrating, have an editor write one real post in the new interface and feed back what tripped them up, so the site does not go stale after launch.
10. Migrating a multilingual site
WordPress multilingual is "each plugin's own way"
WordPress core cannot hold one post in several languages. Multilingual sites rely on plugins or Multisite (several sites from one installation), and the data model differs by approach.
| Approach | How data is stored | What to extract |
|---|---|---|
| Separate post per language | Translations linked by relation | Posts and translation links |
| Several languages in one post | Language delimiters in the body | Split the delimiters |
| Multisite | A separate site per language | Per-site exports and links |
| Machine translation display | Translations in an external or separate table | Where they live, and rights |
Whatever the approach, the key thing to carry over is which posts are translations of each other. WXR may miss plugin-specific links, so export a table of "Japanese URL | English URL | Dutch URL" first.
hreflang must point both ways
hreflang tells Google how language versions relate. Google says each version must list itself and all others, and be listed back; one-way annotations may be ignored. After launch, extract hreflang from every page and compare it with the mapping table. x-default can point unmatched users to a language selector.
11. Launch: freeze, DNS and rollback
From two weeks before to after launch day
Launch is the shortest stage and the one where failures are most visible. DevNJ usually proceeds like this.
| When | What to do | What to check |
|---|---|---|
| 2 weeks before | Lower the DNS TTL (cache time) | Current and new values |
| 1 week before | Announce the content freeze internally | How to handle urgent edits |
| 3 days before | Final export and delta import | Post, image and form counts |
| Day before | Final check with production settings | Redirects, hreflang, noindex |
| Launch day | Switch DNS; keep the old site running | Key pages and form submission |
| 1–30 days after | Monitor Search Console and traffic | Errors, 404s, submission counts |
Keep the freeze short
Anything edited on the old site after the final export will not reach the new one, so you need a content freeze. If conversion is automated with scripts, the freeze can be a few hours to a day.
Keep a rollback ready
In case of serious problems, keep the old site for a while in a state where switching DNS back brings it up immediately. While it remains, restrict access and keep it hidden from search engines.
What to watch after launch
For 30 days, check Search Console's indexing status and errors weekly. If URLs changed, keep redirects for at least one year. The most easily missed failure is form notification emails no longer arriving, so compare submission counts with the previous month.
12. Cost and time ranges
Migration work without a redesign
Cost depends less on page count than on the number of data types, features and languages. The table shows hours for migration work only, excluding redesign, based on DevNJ's working estimates. Amounts use Dutch hourly-rate surveys (freelance web developers €73, agency average €106, both excluding VAT), converted at €1 = ¥175.51 (European Central Bank reference rate, 23 October 2026).
| Size | Assumptions | Hours | Range (€) | Range (¥) |
|---|---|---|---|---|
| Small | About 30 pages, 1 language, 1 form | 40–80 | about 2,900–8,500 | about 0.51–1.49 million |
| Medium | Several hundred posts, 2 languages, a few forms | 120–250 | about 8,800–26,500 | about 1.54–4.65 million |
| Large | Members, integrations, 3+ languages | 300–600 | about 21,900–63,600 | about 3.84–11.16 million |
These ranges apply to any destination type and are not primary-source statistics. Redesign, rewriting and translation cost extra. How to read a full quote is covered in "Website Redesign Cost and How to Read a Quote".
Breakdown of the work
A typical breakdown for a medium site follows. More time on inventory and mapping makes conversion and testing more predictable.
| Task | Hours (medium site) | Grows when |
|---|---|---|
| Inventory and mapping | 16–32 | Many custom post types |
| Export and conversion scripts | 24–48 | Many shortcodes |
| Replacing features | 32–80 | Bookings, members and similar |
| Multilingual links | 16–32 | Translation links are broken |
| Testing and redirects | 16–32 | URLs change |
| Launch and monitoring | 16–26 | A very short freeze is required |
Compare running costs over three to five years, not just upfront cost: hosting, plugin licences and maintenance for WordPress; monthly fees for SaaS; update effort and developer time for a static site or custom CMS. Check amounts against pricing pages and maintenance quotes.
13. Common mistakes
Eight mistakes that often happen
Failures come less from technical difficulty than from checking things in the wrong order. These are the most common in DevNJ's experience.
| Mistake | What happens | How to prevent it |
|---|---|---|
| Starting with the export | Conversion is redone repeatedly | Build the inventory and mapping first |
| Missing shortcodes | Square-bracket text shows in posts | Search and count all body text |
| Not moving SEO settings | Search titles disappear | Give them their own mapping columns |
| Losing image alt text | Accessibility drops | Move alt text as a field |
| Broken translation links | hreflang goes wrong | Build a per-language URL table |
| Form notifications stop | Enquiries are missed | Send a test on launch day |
| Deleting the old site at once | No way back if problems appear | Keep it, hidden, for a while |
| Editors cannot use the new system | Updates stop after launch | Have them write a test post first |
14. Example cases (fictional)
The following are fictional examples to make the reasoning concrete. They are not real companies.
Case 1: A manufacturer's company site updated a few times a year
A Japanese parts manufacturer runs a Japanese–English site of about 25 pages for European customers, updated three or four times a year. It had 18 plugins and was stuck on PHP 8.1.
With few updates and only a contact form, the company moved to a static site generator and handled the form with an external service. URLs did not change.
Case 2: A restaurant group posting every week
A company with three restaurants in the Netherlands updates news and menus weekly in Japanese, English and Dutch. Three managers, all comfortable with WordPress, do the updates.
The complaint was slowness, but the cause was a heavy page builder and large photos. The company rebuilt on WordPress and cut its plugins to eight. Keeping the dashboard the managers already knew was the deciding factor.
Case 3: A language school with bookings and members
A language school in The Hague ran bookings, members and payments through several plugins. Conflicts kept causing double bookings that its maintenance provider could not diagnose.
The school rebuilt bookings and members on a custom framework-built CMS. Rather than implementing compatible password checks, it emailed members in advance and had them reset their password on first login.
| Case | Decision | Deciding factor |
|---|---|---|
| 1. Manufacturer's company site | Static site generator | Few updates, only a form |
| 2. Restaurant group | Rebuild on WordPress | Keeps the dashboard editors know |
| 3. Language school with bookings | Custom CMS | Business features at the core, ongoing conflicts |
15. What changes for sites serving both Japan and Europe
Law and where data lives
For sites aimed at both Japan and Europe, check the law and where data is stored when choosing a destination.
| Item | Japan | Europe (EU, Netherlands) |
|---|---|---|
| Personal data law | APPI | GDPR |
| Entrusting to a provider | Supervise the contractor; Article 28 rules for foreign providers | Processor contract (Article 28) |
| Transfers abroad | Rules on provision to third parties in foreign countries | Conditions such as adequacy (Japan has an adequacy decision) |
| Accessibility | Reasonable accommodation under the Act on the Elimination of Discrimination against Persons with Disabilities | European Accessibility Act (applies from 28 June 2025) |
Japan's Personal Information Protection Commission notes that entrusting personal data to a business abroad can fall under the rules on provision to third parties in foreign countries. Before moving to a SaaS platform or overseas form service, check where the provider handles data.
Does the European Accessibility Act apply?
The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 to services such as e-commerce for EU consumers. Service microenterprises (fewer than 10 staff and turnover or balance sheet of €2 million or less) are exempt.
Japanese businesses selling online to EU consumers can be covered too. Whether a destination can deliver headings, alt text and keyboard operation in line with W3C's WCAG 2.2 is part of the choice. For the Netherlands, see the government portal business.gov.nl.
16. Pre-migration checklist
Deciding
- Counted active plugins and plugins not updated for two years or more
- Checked the PHP version and what breaks when it is raised
- Wrote down who updates the site and how often
- Compared running costs over three to five years
Preparing
- Built an inventory sheet and decided what moves, merges or goes
- Added columns for SEO settings and alt text to the data mapping table
- Added old and new URL columns and decided whether URLs change
- Turned translation links into a per-language URL table
- Confirmed the destination can export your content
Launching
- Prepared password-reset notices for users (if you have members)
- Lowered the DNS TTL two weeks in advance
- Sent a test form submission and confirmed the notification email arrived
- Kept the old site hidden and wrote down the rollback steps
- Scheduled 30 days of Search Console monitoring
Summary
- WordPress runs 39.6% of all websites and 58.3% of CMS sites; leaving it is not a goal in itself
- The maintenance burden sits in unsupported PHP (about 34% of WordPress sites) and plugins, which account for 91% of vulnerabilities
- The two decision axes are update frequency/editors and feature load. If the answers split evenly, tidy up on WordPress first
- Migrate in the order inventory → mapping → export. WXR does not include image files, settings, form submissions or passwords
- Translate plugins into features before replacing them, and separate features you can drop from features you must build
- For multilingual sites, tabulate translation links and check reciprocal hreflang on every page
- At launch, make unchanged URLs the first priority, keep the freeze short and keep a rollback ready
Sources
Usage statistics
- Usage statistics of content management systems — W3Techs: WordPress 39.6%, CMS share 58.3%, other CMSs
- Usage statistics and market share of WordPress — W3Techs: WordPress usage trends
- WordPress Stats — WordPress.org: PHP and WordPress version distribution
- CMS — Web Almanac 2025, HTTP Archive: CMS use over 54%, WordPress about 64.3%, Core Web Vitals pass rates
- CMS — Web Almanac 2024, HTTP Archive: pass rates and Lighthouse medians by CMS
Official WordPress documentation
- Tools Export Screen — WordPress.org: what WXR contains
- WordPress Importer — WordPress.org: importing WXR and attachments
- wp export — WP-CLI: exporting from the command line
- REST API Handbook — WordPress Developer Resources: REST API overview
- Posts — REST API Reference: retrieving posts
- Shortcode API — WordPress Developer Resources: how shortcodes work
- Tools Export Personal Data Screen — WordPress.org: exporting personal data
- WordPress 6.8 will use bcrypt for password hashing — Make WordPress Core: password storage formats
- Requirements — WordPress.org: PHP 8.3 or greater recommended
PHP and security
- Supported Versions — PHP: support end dates for 8.2 to 8.5
- Unsupported Branches — PHP: end-of-life dates for 8.1 and older
- State of WordPress Security in 2026 — Patchstack: 11,334 vulnerabilities in 2025, 91% in plugins
- State of WordPress Security in 2025 — Patchstack: 7,966 vulnerabilities in 2024
Search and performance
- Site moves with no URL changes — Google Search Central: moving without changing URLs
- Site moves with URL changes — Google Search Central: moves with URL changes and how long to keep redirects
- Change of Address tool — Search Console Help: changing domains
- Tell Google about localized versions of your page — Google Search Central: hreflang and x-default
- JavaScript SEO basics — Google Search Central: sites rendered with JavaScript
- Web Vitals — web.dev: LCP, INP and CLS thresholds
Law and accessibility
- Directive (EU) 2019/882 — EUR-Lex: text of the European Accessibility Act and the microenterprise definition
- European Accessibility Act — European Commission: services covered
- European Accessibility Act for products and services — business.gov.nl: guidance for businesses in the Netherlands
- WCAG 2.2 — W3C: accessibility success criteria
- Regulation (EU) 2016/679 (GDPR) — EUR-Lex: processor contracts and transfers abroad
- APPI Guidelines (Provision to Third Parties in Foreign Countries) — Personal Information Protection Commission, Japan: rules when entrusting data to foreign businesses (in Japanese)
Cost calculation
- Euro foreign exchange reference rates — European Central Bank: €1 = ¥175.51 (23 October 2026)
All sources were checked on 24 October 2026. Usage statistics differ in scope and method between surveys, so the figures do not match. The cost and time tables, decision thresholds, and Figures 3 and 4 are DevNJ's estimates based on the sources above and Dutch hourly-rate surveys (covered in Website Redesign Cost and How to Read a Quote); they are not statistics. Legal treatment depends on your business, so consult a professional before signing.
FAQ
- When should a business move away from WordPress to another CMS?
- When who updates the site and how many features it carries no longer match what WordPress is good at. For example, the site is updated a few times a year but plugin updates and security fixes take time every month, or integrations with business systems are being forced through a stack of plugins. A site where several editors publish every week is often better off rebuilt on WordPress.
- Can I export all my WordPress posts and images at once?
- Tools → Export in the dashboard writes posts, pages, custom post types, comments, custom fields, categories, tags and menus to an XML file in a format called WXR. It does not include the image files themselves, theme or plugin settings, or form submissions. Copy the uploads folder separately and use each form plugin's own export for submissions.
- Can I move member passwords to the new system?
- WXR does not contain passwords, so they have to be taken from the database. WordPress 6.8 and later store them in a bcrypt-based format (starting with $wp$2y$); earlier versions use phpass (starting with $P$). If the new system cannot verify these formats, members will need to reset their password on first login.
- Will migrating from WordPress hurt my search rankings?
- If you replace the system without changing URLs, Google treats it as a site move with no URL changes, and the impact can be kept small. If URLs change, you need steps such as keeping 301 redirects from old to new URLs for at least a year. Either way, titles, body text, internal links and structured data must survive the migration.
- How much does a WordPress migration cost and how long does it take?
- For migration work alone, without a redesign, DevNJ's working estimates are 40 to 80 hours for a small site of about 30 pages and 120 to 250 hours for a bilingual site with several hundred posts. At Dutch hourly rates of €73 to €106, that is roughly €2,900 to €8,500 and €8,800 to €26,500. Allow 4 to 6 weeks and 2 to 4 months respectively.
- What should I watch for when migrating a multilingual WordPress site?
- WordPress core has no built-in way to hold one post in several languages; multilingual sites rely on plugins or Multisite. Before migrating, export a table showing which posts are translations of each other. After launch, check on every page that hreflang annotations point to each other in both directions.
Planning a site that has to work in both markets?
Get in touch
