After PHP2Shell, a WordPress migration can mean changing hosting providers, replacing the CMS, or publishing a static copy. Each changes a different part of the system. Start by verifying the PHP fix for your current site, then decide which maintenance responsibilities and features you want to keep.
The WordPress incident announcement identifies a PHP problem that affects multiple applications. It does not establish that every WordPress site needs a different CMS. The decision below focuses on operational requirements, with a migration checklist for the route you choose.
Update PHP, change hosts, or migrate WordPress?
Choose based on the problem you need to solve:
| Situation | Route to evaluate | Evidence needed before committing |
|---|---|---|
| The site works and its owner can maintain PHP | Install a vendor-confirmed PHP fix | Correct deployed runtime, compatibility checks, and a responsible maintainer |
| WordPress fits, but the host cannot provide timely patching | Move to a provider with suitable managed operations | Target runtime fix, patch ownership, restore process, support scope, and total cost |
| A publication needs posts, pages, and a simpler editorial workflow | WordPress to Ghost | Representative imports, content permissions, media, redirects, and publishing tests |
| A content site can publish without a public PHP application | Static output, potentially built with Astro | A working publishing process and replacements for every required dynamic feature |
| Editors need WordPress while developers replace its frontend | Headless WordPress with a separate frontend | A maintained PHP backend, controlled access, and a tested content delivery path |
| Revenue depends on complex commerce or custom plugins | A staged feature and data assessment | Orders, accounts, integrations, permissions, and rollback verified on the candidate platform |
A change of PHP branch, a hosting move, and a CMS replacement have different costs and failure modes. Write down the required result before choosing a migration tool.
WordPress hosting migration: keep the application, change the operator
A hosting move can make sense when responsibility is the problem: nobody owns runtime updates, restores are untested, or the provider cannot identify the build serving your site.
Ask the destination provider who maintains PHP, WordPress core, themes, and plugins. Confirm how patching, backups, restores, staging, and incident support are handled and priced. “Managed” is a service description whose actual scope needs checking.
A WordPress migration plugin may help transfer data, but a successful transfer does not certify the target runtime. Obtain the destination’s PHP2Shell fix confirmation before switching traffic. WordPress’s migration handbook is a starting point for moving installations.
Keep separate full backups of the database and site files. The Tools → Export XML is a content-transfer format, described in the WordPress export documentation. It is not a complete replacement for the database, uploads, application files, and configuration needed to restore the installation; WordPress’s export implementation explicitly distinguishes it from a full backup.
If compromise is suspected, preserve the relevant evidence and have the installation assessed. Copying the same files to a new host is not proof that an intrusion has been removed.
WordPress alternatives: what would you have to replace?
Evaluate a destination against actual content and workflows, rather than a general “best WordPress alternatives” ranking. Select a few representative pages: a plain article, a page-builder layout, an important landing page, and any restricted or transactional page.
WordPress to Ghost for a publication
Ghost provides an official WordPress migration workflow using exported XML. Its documentation describes importing posts and pages, with limits and exclusions including custom post types, some shortcodes, and plugins that control access to content.
Test representative content before planning the complete move. In particular, check restricted articles, embedded media, author information, and category-to-tag changes. Recreate the required design and access rules in the destination, and inspect the resulting URLs. An accepted import file does not prove the old site’s behavior has been reproduced.
WordPress to Astro or another static publishing workflow
Static publishing can remove the need to execute PHP for public page requests when the deployed system actually serves static files and the old PHP service is no longer publicly reachable. It still needs a maintained build pipeline, editor access, and any external services used by the site.
Inventory functionality that previously depended on WordPress: forms, search, comments, previews, scheduled publishing, accounts, and payments. Decide how each required function will work before approving the move. Replacing the page renderer alone does not transfer these behaviors.
Headless WordPress still has a PHP backend
The Astro and WordPress guide shows how Astro can fetch content from a WordPress API. In that architecture, WordPress remains a content system, with PHP and its own maintenance requirements.
Draw the actual request path. Can visitors still reach the old WordPress hostname, API, administration, or origin? Which endpoints must remain available for publishing? A static frontend does not patch those services. Patch the backend and apply access controls suitable for the content workflow.
WordPress migration checklist: preserve content, features, and SEO
Use the following as a cutover worksheet for any destination:
| Area | Check on a staging copy | Completion evidence |
|---|---|---|
| URLs | Match existing paths where possible; map every changed important URL | Old URL, intended destination, and actual HTTP result |
| Content | Import representative layouts, custom fields, and shortcodes | Reviewed pages with required content intact |
| Media | Check original files, inline images, downloads, and embeds | Assets load without depending on a retiring server |
| Features | Exercise forms, search, accounts, and any purchase flow | Recorded outcomes, permissions, and notifications |
| Editing | Have the owner publish, edit, preview, and remove a test item | The publishing workflow can be completed by its intended user |
| Search signals | Inspect titles, canonicals, indexability, internal links, and sitemap | Production URLs appear consistently and are eligible for indexing |
| Runtime | Verify the destination’s patching and the status of the old PHP service | Identified maintained runtime or confirmed removal of the public PHP service |
| Recovery | Establish traffic rollback and data reconciliation steps | Named owner, usable backups, and a tested recovery procedure |
Google’s site-move guidance recommends mapping changed URLs and using permanent redirects. Send a retired article to its relevant replacement; redirecting unrelated pages to the homepage does not preserve their meaning. When a URL stays the same, make sure it still serves the intended content.
Protect staging from public access or indexing as appropriate, then confirm production is crawlable at launch. Check that staging-only noindex directives and access restrictions were not carried over. After cutover, submit the production sitemap and monitor important URLs in Search Console. Search visibility can fluctuate while Google processes a move; no migration tool can guarantee unchanged rankings.
For a site accepting orders, registrations, or comments, plan how writes made during the transition reach the final system. A DNS rollback alone cannot reconcile records created in two places. Keep the old system only as long as operationally needed, patched and access-controlled.
Make the decision with a small proof first
Before moving the entire site, demonstrate one complete publishing flow and one critical visitor journey on the candidate destination. Record what survived, what required rebuilding, and who will maintain each remaining service. Then compare migration work and recurring costs with maintaining or rehosting the existing application.
If the urgent constraint is an unpatched legacy runtime, use the PHP2Shell mitigation guide while arranging a verified fix. A planned CMS change does not protect the PHP installation that remains online during the project.
Reviewed on October 22, 2026 against the linked official documentation. This is a decision and acceptance guide, not a claim that BuzzPHP has completed a WordPress-to-Ghost or WordPress-to-Astro production migration. Migration-tool limits and hosting responsibilities should be checked for the actual destination.