Moving off WordPress? Start with the business case.

A WordPress migration is worth doing when it solves a business problem: slow publishing, ongoing security maintenance, poor performance, or a site your team cannot improve. Start by defining that problem. Then plan the move around the content, search visibility, and enquiries the site already earns.

The replacement platform is a decision that comes later. First, work out what the website needs to make easier for the people using it and the team running it.

What is the business case for moving?

A request for a new website often starts with frustration. A landing page takes too long. A plugin update breaks something. Marketing has a useful idea, but publishing it means opening a ticket and waiting.

Those frustrations deserve a closer look. Write down the last three changes your team wanted to make. For each one, record what changed, who touched it, how long it waited, and how much work it took. That turns a vague complaint about the website into something you can improve.

Sometimes the right answer is a better editing process on the current site. Sometimes it is removing an unnecessary integration or fixing a template. When the platform keeps creating the same friction, a replacement becomes easier to justify.

The October PHP security alerts make the cost tangible

On October 21, 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Under exploitable conditions, an attacker could run code on an affected server without signing in. The project urged all PHP installations serving web requests to update, with the highest demonstrated risk on Apache's mod_php configuration. See the PHP security advisory.

WordPress published its own critical PHP security notice the same day. It asked site owners to check with their hosts and update PHP. These flaws affect the underlying PHP runtime used by WordPress and other applications; updating WordPress itself does not apply the PHP fixes.

On October 23, PHP also described a separate session-related issue, CVE-2026-115560, involving an unusual combination of configuration and application behavior. Its follow-up advisory provides a temporary mitigation pending the next regular bugfix release. In its October 23 update, the Dutch National Cyber Security Centre said exploitation of the earlier flaws was more complex than initially estimated and continued to urge prompt patching.

The replacement architecture matters. A static frontend backed by a publicly reachable WordPress installation still leaves that PHP backend to maintain. Moving to another PHP-based CMS keeps the runtime dependency, too. Include retiring or properly isolating the old installation in the migration scope. Hosting, accounts, forms, integrations, and deployment tooling still need their own security care.

For an affected site, the immediate job is to follow the current PHP and hosting-provider guidance and apply the security updates. A migration is a longer-term decision about how much infrastructure the business needs to keep operating.

Measure the starting point

Choose a small set of measures that reflects the reason for moving. If publishing is the problem, track the time from an approved change to a live page. If the website is slow, measure actual loading and interaction performance. If organic acquisition matters, record which pages bring in relevant visitors and enquiries.

Keep the definitions consistent. A request that includes a new design and three rounds of copy review is different from correcting a sentence. Separate the queue, the work, and the approval process so you can see which part improves.

Core Web Vitals provide a useful framework for loading, responsiveness, and visual stability. Keep those measurements separate from an on-page SEO audit score. They answer different questions.

Preserve what buyers already find

Before changing the site, identify the pages that matter. A page can be valuable because it brings in enquiries, helps a sales conversation, or answers a question that would otherwise take your team time. Traffic is one signal in that inventory.

Retain useful URLs where practical. For URLs that change, map each old page to a relevant destination and test the permanent redirect. Carry across important content and metadata, update internal links, and check that the new site can be indexed. Google's site-move guidance explains those steps and recommends retaining redirects for at least a year.

Make the URL map part of the handoff. Someone needs to own it after the launch project ends. The same applies to domains, hosting accounts, analytics access, and the recovery process.

Demonstrate the editing workflow early

A site is easier to maintain when the publishing process fits the team. That might mean a visual editor, a small CMS, or an AI-assisted process. The choice should follow the work people need to do.

Before approving the build, ask for a demonstration of three ordinary tasks: change a service description, publish an article, and update a call to action. Have the person who will maintain the site try them. Include previewing the result, checking it on a phone, and recovering an earlier version.

An editing workflow that only works while the developer is on the call leaves the team dependent on that developer. The handoff needs to cover the ordinary week after the project is finished.

Launch in stages and check the whole journey

Give the migration a clear finish line. Agree which pages and integrations are in scope, what needs to work before launch, and what will be checked afterwards.

Review the site as a buyer would: arrive on an article, follow a link to a service, submit an enquiry, and check that the right person receives it. Then review it as the operator: find the enquiry in analytics or the CRM, make an edit, and confirm that the update is visible.

Keep a backup and an agreed recovery route. Stage major changes where practical. Google advises changing substantial elements in sequence and notes that search visibility can fluctuate while a move is processed. That makes a clear baseline and a named owner for launch checks useful parts of the project.

What LeanLaw and PostHire illustrate

LeanLaw moved away from WordPress and saw a 300% increase in organic traffic over six months, alongside faster load times. Website changes went from taking one to two weeks to under 30 minutes.

PostHire also moved off WordPress. Its on-page SEO score improved from below 50 to above 90, and the team gained a way to make website changes through ChatGPT, its chosen AI tool.

Those results describe different benefits. LeanLaw's traffic result measures acquisition; the publishing result measures operating speed. PostHire's audit score measures on-page checks, while its editing workflow describes what the team can now do. They are useful together because a better website should support both buyers and the people maintaining it.

The examples do not isolate the platform change as the cause of every improvement. They show why the business case should include the complete project: content, technical work, and the publishing process.

Make the decision around the next year of work

Ask how often the team needs to publish, which integrations matter, and who will maintain the site. Compare the full running cost, security patching responsibilities, and practical editing process for each option. A platform that fits a large publishing operation may be unnecessary for a focused B2B marketing site.

If the current site can support the work with a few targeted changes, start there. If the platform repeatedly holds the team back, scope the move around the outcomes you want to measure. You can see how I combine that work with search and content in the SEO, AEO and WordPress migration service.