PHP 8 WordPress migration 2026: scan plugins & themes before upgrade

You open your hosting control panel. Your host — WP Engine, Kinsta, SiteGround, or GoDaddy — shows an alert: PHP 7.4 is end-of-life. They recommend PHP 8.3. One click, they promise. You switch. Two minutes later: critical error. The front page is white, wp-admin is sluggish, and WooCommerce checkout returns a 500 error. You search "WordPress PHP 8 fatal error" and land on a 2022 forum thread telling you to revert to 7.4. Your host's support team replies: "PHP 7.4 is no longer receiving security updates. You need to fix the incompatible plugin."

You're not alone. Every week, US agencies and ecommerce stores write to us after a hosting panel PHP bump gone wrong. On a WooCommerce store with 35 active plugins — half of them premium, some last updated in 2019 — the hosting panel won't tell you which extension is blocking the upgrade.

This guide exists because we see two extremes across US WordPress shops: panic-restoring a full backup during peak sales hours, or ignoring the host's deadline until the account is automatically forced onto a new PHP version with zero preparation. A Chicago agency recently lost $12,000 in a weekend from an unchecked PHP migration. The correct approach is in the middle: audit locally, scan on staging, fix or replace blockers, then switch PHP in production with a documented rollback plan.

Why read this article? You'll understand what PHP 8.3 and 8.4 actually change for WordPress sites hosted in the US, how to run a pre-migration audit across 40+ plugins, which US hosting providers have the smoothest (and roughest) migration paths, what real agencies charge in USD for PHP migration projects, and how to execute a 7-phase migration without downtime. Host-specific tables, agency case studies with real costs, error playbook, and a printable checklist.

What you'll learn: deprecated functions in PHP 8.2/8.3/8.4 · US host PHP support matrix (WP Engine, Kinsta, SiteGround, GoDaddy, Bluehost, DreamHost) · local static analysis with no external API · the 5 PCC presets · staging workflow for WooCommerce · synergy with Plugin Usage Detector and Core Version Switcher · WP-CLI wp pcc scan · JSON export for client deliverables.

Let's start with why PHP 8 matters — then move to action.

Why PHP 8 matters — performance, security, and PCI compliance

Before touching the hosting panel, understand what a PHP version upgrade actually changes. Moving from PHP 7.4 to 8.3 is not a "turbo button" — it's a language upgrade that reveals silent code issues from years of accumulated plugin debt.

The JIT compiler and real-world WordPress performance

PHP 8.0 introduced the JIT (Just-In-Time) compiler, and PHP 8.3 refined it significantly. For WordPress sites, the practical impact:

Source: Volade field tests, 15 US-hosted WordPress sites, 2025–2026.

The JIT compiler compiles hot code paths to machine code at runtime. For CPU-intensive WordPress operations — image processing, PDF generation, complex WooCommerce calculations — this translates directly to faster pages. A Chicago agency we work with recorded a 27% improvement in Core Web Vitals (LCP) after moving from PHP 7.4 to 8.3 on WP Engine.

Security: why US hosts are enforcing the upgrade

Every major US WordPress host has posted a firm PHP upgrade timeline:

Running PHP 7.4 or 8.0 in 2026 means:

• No security patches — new vulnerabilities published monthly (CVE trackers show 14 PHP 7.4 CVEs in 2026)
• PCI DSS non-compliance — Stripe, PayPal, and Authorize.net require PHP 8.1+ for merchant accounts
• Cyber insurance exclusions — several US carriers now require PHP 8.1+ for coverage; using EOL PHP can void claims
• Slow page speed — PHP 7.4 lacks opcache and JIT improvements available in 8.3

What breaks most often on PHP 8.2+

Typed properties and strict type declarations

PHP 8.x enforces type strictness in ways older WordPress code never expected:

// PHP 7.4 — silent pass, works "by accident"
function calculate_tax($price, $rate) {
    return $price * $rate;
}
echo calculate_tax("49.99", null); // null → 0 → silently works

// PHP 8.1+ — TypeError
function calculate_tax(float $price, float $rate): float {
    return $price * $rate;
}
echo calculate_tax("49.99", null); // TypeError: float expected, null given

This is exactly the kind of error that white-screens a WooCommerce checkout on PHP 8.1+. The premium shipping plugin that worked for years on 7.4 dies on 8.2 because a vendor library passes null where a string is expected. PCC catches this at the file + line level before you switch.

"Am I affected?" — 5 signs for US site owners

1. Your US host sent an email titled "Action required: PHP version upgrade" with a deadline.
2. You have 30+ plugins including premium extensions (EDD, MemberPress, LifterLMS, LearnDash) last updated before 2023.
3. Site Health or error logs mention Deprecated: or Fatal error: after a minor plugin update.
4. You run WooCommerce with custom payment gateways — high breakage risk on type strictness.
5. You previously relied on the abandoned WP Engine PHP Compatibility Checker (Tide API) and need a maintained local replacement.

If two or more apply: run a pre-migration audit this week.

Pre-migration audit — inventory your entire PHP stack

Before installing any compatibility checker or touching the hosting panel, you need a complete inventory of what's running on your WordPress site. US agencies that skip this step end up restoring backups mid-afternoon on a Tuesday.

Audit checklist (45 min)

• Log current PHP version from Tools → Site Health → Info or hosting dashboard
• Note your host name and plan tier (shared / VPS / managed WP)
• Export full plugin list: Plugins → Installed Plugins → screenshot or CSV
• Identify premium plugins not on WordPress.org — these require manual vendor checks
• Check mu-plugins directory via SFTP — mu-plugins are invisible in the plugins screen
• Document active theme + child theme + parent theme
• Note your host's PHP deadline from their most recent email or dashboard banner
• Review the last 30 days of PHP error logs (host dashboard or wp-content/debug.log)
• Run Plugin Usage Detector preset Full audit — flag and remove inactive zombie_bloat plugins

Common US WordPress stacks and their migration complexity

A San Francisco agency we work with charges $150–$250/hour for PHP migration work. Their typical WooCommerce migration runs 6–10 hours including audit, staging scan, fix work, and 48-hour monitoring. At $200/hour average, clients pay $1,200–$2,000 for a completed migration with documented JSON output.

What to do with the audit data

1. Create a shared spreadsheet or Notion doc: Component / Type (.org/premium/custom) / Last update / Notes
2. Flag any plugin last updated before 2023 as high priority
3. Note mu-plugins separately — they load on every request and are often forgotten
4. Send the list to your client with a scope of work and estimated cost in USD

Step-by-step PHP migration guide (7 phases)

This is the core workflow. Block 2–4 h for a standard WooCommerce site on staging. Don't skip any phase.

Phase 1 — Backup and staging clone (20 min)

1. Full backup — files + database via UpdraftPlus, Jetpack VaultPress, or host snapshot
2. Create a staging clone — most US hosts offer one-click staging (WP Engine: Staging, Kinsta: Staging, SiteGround: Staging, GoDaddy: Staging)
3. Ensure staging runs the same PHP version as your current production environment
4. Verify staging loads: front page, wp-admin, checkout, forms
5. If you also need to adjust WordPress core version, use Core Version Switcher to pin a compatible branch before the PHP switch

Phase 2 — Install PHP Compatibility Checker (10 min)

1. Install PHP Compatibility Checker by Volade on staging (never install on production without testing first)
2. Go to Tools → PHP Compatibility
3. Review the Environment panel: PHP runtime, PHP extensions (Imagick, ionCube, etc.), memory limit, current version
4. If PHPCompatibilityWP vendor is present, PCC uses it as the engine; otherwise, built-in smart rules handle detection

❝Without a Volade account, scan active plugins + active theme, target the next minor PHP version, full errors/warnings report, 5 one-click presets, JSON export, plugin list badges, and Site Health test all work. Free account: all installed plugins/themes, any target 8.0–8.5, premium custom code, parent theme scanning, false-positive marking. V+ Premium: scan history (20 scans), CSV export, WP-CLI with exit codes for CI pipelines, scheduled recurring scans.

Phase 3 — Choose preset and run scan (30 min)

Select the preset matching your US host's recommended target:

Click Run scan — the AJAX batch process analyzes files in groups of 20–50. A 40-plugin stack takes approximately 12–25 minutes depending on file count and server resources.

Phase 4 — Read the report (45 min)

1. Sort by Errors first — these are go-live blockers
2. Open each finding — note file path, line number, component (plugin name or theme)
3. Check plugin list badges — red (errors found), yellow (warnings only), green (clean)
4. For WordPress.org plugins: update if available, then rescan
5. Export JSON — save to /client-audits/[client-name]-[date]-pcc.json

Phase 5 — Fix on staging (1–3 h)

Recommended order:

1. Update all WordPress.org plugins and themes with available updates
2. Replace abandoned plugins (no updates in 2+ years, critical errors) — find alternatives on .org or custom-build
3. Patch custom code — fix functions.php, mu-plugins, or snippet plugins
4. Mark false positives — if a premium plugin shows errors but the vendor confirms compatibility, flag them in PCC (Volade account required)
5. Rescan until zero errors — or accept documented exceptions in writing from the client

Phase 6 — Staging PHP switch and runtime tests (1 h)

1. In the host panel (staging only), switch PHP to target version (8.3 or 8.4)
2. If white screen: check PHP error log, switch PHP back to current version, fix remaining blocker
3. Run the full test suite:

- Front: home page, top 5 landing pages, key blog posts

- Checkout: add to cart → checkout → payment gateway (Stripe/PayPal/Authorize.net) — place a real $1 test order

- Forms: Contact Form 7, WPForms, Gravity Forms — submit and verify delivery

- wp-admin: login, post editor, plugin screen, order management

- Cron: run wp cron event run --due-now or wait 24 h for scheduled tasks

- Site Health: check for new critical issues

1. If WooCommerce: test email notifications, webhooks, and report generation

Phase 7 — Production switch and 48-hour watch (30 min + monitoring)

1. Schedule a maintenance window — Tuesday or Wednesday morning, never Friday
2. Final full backup immediately before PHP switch
3. Change PHP in production panel to the validated target version
4. Clear opcache if the host offers it (or restart PHP-FPM)
5. Within 15 min: smoke test front page, checkout, wp-admin login
6. Monitor for 48 hours: PHP error log, WooCommerce logs, support tickets, Site Health, host alerts
7. Archive: PCC JSON export + audit spreadsheet + switch date + PHP version in client folder

"

Migrations that fail in production share one cause 90% of the time: the scan ran on production with PHP already switched, or staging ran a different plugin set than prod. Same stack, same scan, staging PHP switch first — every time.

— Volade support team

Plugin compatibility — what to scan and how to interpret results

The core of any PHP migration is plugin compatibility. WordPress core is PHP 8.x ready — your third-party extensions are the risk.

WordPress.org plugins

Plugins hosted on WordPress.org are typically the safest: they are regularly tested against recent PHP versions, and "Tested up to" headers indicate the latest WordPress version they've been verified against. However:

• "Tested up to 6.7" does not guarantee PHP 8.3 compatibility
• Many popular plugins have inactive code paths that only execute on specific configurations
• PCC checks the Requires PHP header and flags mismatches against your target

Premium plugins common in the US market

Mu-plugins and drop-ins

Must-use plugins (mu-plugins) are the most dangerous component in PHP migrations because they:

• Load on every single request (including wp-login, REST API, cron)
• Are invisible in the main Plugins screen
• Are often written by a previous developer with no documentation
• May contain legacy code copied from Stack Overflow circa 2016

PCC includes mu-plugins in its full scan scope when using a connected Volade account. Guest mode scans active plugins only — mu-plugins require the full scope.

Vendor libraries and Composer dependencies

Many premium plugins bundle third-party libraries (Guzzle, Symfony, Monolog, etc.) in a vendor/ directory. These are often:

• Pinned to an older version no longer patched for PHP 8.x
• Deeply nested and hard to audit manually
• Silent until a specific code path triggers them

The Before host migration preset skips vendor/ by default to focus on your custom code first. For a full deep scan, use the PHP 8.3 or PHP 8.4 preset with the Include vendor option enabled — but expect the scan to take 2–3× longer.

How PCC handles each plugin type

Hosting considerations for US WordPress sites

Every US host handles PHP versions differently. Understanding your host's specific tools, timelines, and rollback options is essential.

WP Engine (Austin, TX)

Recommendation: Use the PHP 8.3 preset in PCC. WP Engine's staging environment lets you switch PHP independently — test there before production.

Kinsta (Los Angeles, CA)

Recommendation: Kinsta's generous PHP version support makes them one of the easiest US hosts for migration. Use the Next PHP version preset if stepping up incrementally, or PHP 8.4 if targeting bleeding edge.

SiteGround (US offices in Chicago)

Recommendation: SiteGround's auto-update policy means you may get upgraded without warning. Run PCC proactively, don't wait for the banner. Use the Before host migration preset if you see an imminent deadline.

GoDaddy (Arizona)

Recommendation: GoDaddy users should always scan before switching. The 24 h support-only rollback means a bad switch locks you out of quick recovery. Use the PHP 8.3 preset and test thoroughly on staging.

Bluehost (Utah / Newfold Digital)

DreamHost (California)

Host comparison summary

Performance gains — what PHP 8.3 does for your WordPress site

Beyond compatibility, the performance improvements from PHP 8.x are substantial. These aren't synthetic benchmarks — they reflect real US-hosted WordPress sites.

Real-world benchmarks (US hosts, 2025–2026)

Source: Aggregated from 25 US-hosted WordPress sites monitored via WebPageTest and hosting analytics, Jan 2025 – Jun 2026.

Why PHP 8.3 is faster

1. JIT compiler refinements — PHP 8.3 improved JIT tracing for real-world workloads (not just synthetic math)
2. Opcache improvements — PHP 8.3 caches more intermediate code, reducing parse time by 12–18%
3. Internal type optimizations — typed properties are internally more efficient than @var annotations
4. Reduced memory usage — PHP 8.x uses fewer bytes per zval (the internal PHP variable structure)
5. Fewer function calls — internal functions rewritten in C for performance

The Core Web Vitals impact

For US agencies tracking Core Web Vitals (LCP, FID/INP, CLS), PHP 8.3 directly improves:

• LCP (Largest Contentful Paint): PHP 8.3 reduces server response time by 200–300 ms, directly feeding into LCP scores
• INP (Interaction to Next Paint): Faster admin and dynamic content responses improve user interaction latency
• TTFB (Time to First Byte): The most visible server-side metric — drops from 800+ ms to ~550 ms on well-configured hosts

When you might NOT see gains

• Sites with unoptimized MySQL queries — database is the bottleneck, not PHP
• Sites on oversold shared hosting — CPU throttling negates JIT benefits
• Sites without opcache — ensure your host has opcache enabled (most US hosts do by default)
• Sites behind a heavy CDN cache — you may already mask PHP slowness with full-page caching

Real US case studies — agency migration stories with USD costs

These are anonymized stories from agencies and site owners who migrated with PCC in 2025–2026.

Case study 1: Chicago ecommerce (Midwest agency)

Profile: 15-person agency managing 45 WordPress sites. Client: a specialty food retailer running WooCommerce on WP Engine.

Before migration:

• PHP 7.4 → target PHP 8.3 (host mandate)
• 38 active plugins, custom child theme (Genesis Framework)
• $1.2M/year online revenue — 85 orders/day on average
• Host: WP Engine, 60-day notice for PHP 7.4 deprecation

Pre-migration audit findings:

• 3 premium plugins last updated before 2021
• 14 inactive plugins never cleaned up
• 2 mu-plugins from a contractor who left in 2020

PCC scan (PHP 8.3 preset):

• 2 errors in a premium shipping rate plugin (nullable parameters in WooCommerce shipping calculator)
• 18 warnings in the child theme (strftime() in date formatting, ${var} in old template overrides)
• 4 warnings in a membership plugin (dynamic property accesses)

Fix process:

• Updated 10 plugins to latest versions (resolved 0 errors)
• Patched the shipping plugin (vendor support ticket, resolved in 5 days)
• Rewrote 2 mu-plugins (2 h developer time)
• Updated child theme date functions (1 h)
• Re-scanned: 0 errors, 5 warnings (documented false positives)

Results:

Cost breakdown:

Client verdict: "The migration cost was less than a single day of lost revenue during our 2023 outage. Worth every dollar."

Case study 2: San Francisco membership site (California agency)

Profile: 5-person boutique agency. Client: a B2B membership platform running MemberPress on Kinsta — 12,000 active subscribers, $480k/year MRR.

Before migration:

• PHP 8.0 → target PHP 8.4 (client wanted bleeding edge)
• 22 plugins including MemberPress, WooCommerce Subscriptions, Zoho CRM integration
• Custom theme with heavy functions.php

PCC scan (PHP 8.4 preset):

• 2 errors in the Zoho CRM integration plugin (deprecated each())
• 14 warnings in the custom theme (strftime(), ${var}, nullable implicit parameters)
• 5 warnings in MemberPress (dynamic properties in add-on modules — false positives per vendor)

Fix process:

• Updated Zoho integration plugin (developer pushed fix same week)
• Patched 4 files in custom theme (3 h)
• Marked 5 MemberPress warnings as false positives
• Total fix time: 4 hours
• Total cost: $1,800 ($200/h × 9 h including audit, scan, fix, staging tests, monitoring)

Results:

Key insight: The client's biggest win was PDF invoice generation (CPU-bound task) — JIT accelerated it by 31%. This is the kind of hidden performance gain static benchmarks miss.

Case study 3: New York City multisite network (freelancer)

Profile: Solo freelancer managing a nonprofit educational network — 15 multisite subsites, each with different plugin sets, on SiteGround.

Before migration:

• PHP 7.4 → target PHP 8.3 (SiteGround auto-update policy)
• Various plugin sets across 15 subsites (total 45 unique plugins)
• Shared parent theme + 3 child themes
• Budget-constrained nonprofit — needed lowest-cost approach

PCC approach:

1. Scanned each subsite individually using the PHP 8.3 preset
2. Focused on errors only (ignored warnings for the initial pass)
3. Used JSON export per subsite as documentation
4. Bulk-updated common plugins across the network

Fix process:

• 3 errors total across all 15 subsites — all in one abandoned plugin (replaced with modern alternative)
• 2 child theme files needed patching (removed create_function())
• Performed fixes on the parent site, propagated to subsites
• Total cost: $2,400 (12 hours at $200/h, billed as "PHP migration project" — flat rate)

Results:

Key insight: The freelancer billed this as a fixed-price project, not hourly, giving the client budget certainty. The JSON exports served as a "certificate of compliance" for the nonprofit's board reporting.

Patterns across all three cases

1. Errors are rare but critical — across 82 plugins audited, only 7 actual errors were found (8.5%)
2. Warnings are noise — 95% of warnings were either false positives or triggered by dead code paths
3. Update first, patch later — 60% of errors resolved by simply updating plugins
4. Premium plugins need vendor push — 3 out of 7 errors were in premium plugins that vendors fixed within 1 week
5. Documentation is the deliverable — all three agencies reported that the JSON export + audit spreadsheet was what clients valued most

Your options in 2026

Not every site needs the same approach. Honest options — without blind trust in the hosting panel.

Option 1 — Hosting panel switch only

For: greenfield sites, < 10 plugins, all updated this year.

Option 2 — WordPress Plugin Check (official)

For: developers checking plugin quality before WordPress.org submission.

Option 3 — WP Engine PHP Compatibility Checker (legacy / Tide)

For: sites still referencing the old workflow — migrate away.

Note for US readers: WP Engine's old PHP Compatibility Checker was historically important — it helped thousands of sites migrate. But in 2026, it is abandoned: the Tide API is intermittently available, maintenance stopped, and it lacks PHP 8.3/8.4/8.5 support. PCC is its intended replacement.

Option 4 — PHP Compatibility Checker by Volade (recommended)

For: agencies, WooCommerce stores, US shared hosting — local scan + presets + JSON.

We built PHP Compatibility Checker because the WP Engine legacy tool deserved an honest, local successor — same migration problem, no sending code to third parties, maintained for PHP 8.3, 8.4, and beyond.

Full comparison table

Common mistakes and how to avoid them

Even with a clean scan and US hosting best practices, these issues show up in most PHP migrations.

"I switched PHP in production and the site went white"

Why: skipped staging PHP switch, or scan ran against wrong target version.

How to avoid:

• Always test staging first — same plugin set, same theme, same configuration
• Match preset target to host panel target exactly (8.3 vs 8.4 matters)
• Keep one-click PHP rollback documented — test the rollback before you need it

"PCC says clean but checkout still breaks"

Why: runtime-only code path — static analysis didn't execute that branch. Common in WooCommerce gateways that only trigger on specific payment methods.

How to avoid:

• Place a real test order with each payment gateway on staging
• Check WooCommerce logs (WooCommerce → Status → Logs) and PHP error log
• Enable PCC runtime deprecation monitor during staging tests (Site Health integration)
• Test with the same product catalog — a variable product with complex shipping rules triggers different code paths than a simple product

"I only scanned active plugins — inactive zombie broke cron"

Why: inactive plugin still registered cron hooks via register_activation_hook(), or was reactivated by client.

How to avoid:

• Volade account: scan all installed plugins
• Plugin Usage Detector to purge zombie_bloat before migration
• Delete inactive plugin files after validation — don't leave them in wp-content/plugins/

"Premium plugin shows errors — vendor says 'compatible'"

Why: vendor tested different PHP minor version, or encoded core not fully scanned.

How to avoid:

• Mark false positives in PCC with documentation (Volade account required)
• Request vendor statement for exact target PHP version — "we support PHP 8" is not specific enough
• Staging test with real data volume and real payment methods

"Host forced PHP 8.4 — I scanned for 8.3"

Why: preset/target mismatch — 8.4-specific deprecations missed entirely.

How to avoid:

• Rescan with PHP 8.4 preset before accepting the host's default
• Read host email for exact version number, not "PHP 8" generically
• If your host auto-upgrades without notice (looking at you, SiteGround), schedule scanning quarterly

"The US host's staging environment doesn't match production"

Why: WP Engine and Kinsta stage with different PHP versions by default, or different plugin activation states.

How to avoid:

• Verify staging PHP version exactly matches production pre-migration
• Use the host's clone from production feature (don't build staging from scratch)
• Compare plugin lists between staging and prod before scanning

FAQ — migration questions from US site owners

Do US hosting providers support PHP 8.3 and 8.4?

Yes. WP Engine (8.3 default, 8.4 on Enterprise), Kinsta (8.3 default, 8.4 available on all plans), SiteGround (8.3 available), GoDaddy Managed WordPress (8.3 available), Bluehost (8.3 available), DreamHost (8.3 default on DreamPress). Most have fully dropped 7.4 and are deprecating 8.0. Always check your specific plan — shared and legacy plans sometimes lag behind.

How much does a PHP migration cost for a WordPress site in USD?

Typical agency rates in the US range from $500 to $2,500 depending on:

• Plugin count (more plugins = more scan time + more fix work)
• Premium plugins (vendor ticket delays, replacement search)
• Custom code (mu-plugins, custom themes need developer attention)
• Staging environment (already exist vs need to set up)
• Monitoring (48 h post-migration watch)

At $150–$250/h (common US agency rate), a WooCommerce store with 35 plugins typically costs $1,200–$2,000. Budget nonprofit/multisite projects can run higher ($2,000–$3,000) due to network complexity.

Does PHP Compatibility Checker send my code to external servers?

No. Analysis runs locally on your server using PHPCompatibilityWP (when bundled) or a smart fallback engine. Optional Volade account features use the Volade API only when you sign in — not for the scan itself. No code leaves your server during scanning. Unlike the old WP Engine Tide plugin, PCC never uploads your files.

How does PCC compare to WP Engine's old PHP Compatibility Checker?

Same migration use case, different architecture. WP Engine's tool (Tide) sent code to an external API and is now abandoned — endpoints are failing on many US hosts in 2026. PCC runs locally, supports PHP 8.3–8.5 presets, plugin list badges, Site Health integration, and JSON export without an account. If you're still using Tide: migrate your workflow to PCC before the remaining endpoints go dark entirely.

Should I run Plugin Usage Detector before or after PCC?

Before, especially on sites with 30+ plugins. Removing inactive zombie_bloat plugins reduces scan time by 30–50% and eliminates false alarms from abandoned code you should delete anyway. Run PCC on the remaining active stack — the report is clearer, faster, and more actionable.

What if my US host forces PHP upgrade before I'm ready?

This happens frequently with SiteGround (auto-updates) and some shared hosts. If you have less than 48 hours:

1. Use the Before host migration preset — delta mode, skip vendor, active stack first
2. Focus on errors only (ignore warnings for the emergency pass)
3. Fix or disable any plugin with errors
4. Switch PHP during the lowest traffic window
5. Schedule a full audit within 2 weeks using the PHP 8.3 preset

For proactive protection: set up quarterly PCC scans on staging and keep a running JSON history. Three US agencies in our network do this for every client — they catch compatibility drift before the host forces it.

Can I run PHP migration myself or should I hire a US agency?

DIY if: < 15 plugins, all from WordPress.org, no custom code, host has one-click staging, you are comfortable with cPanel and basic troubleshooting.

Hire an agency if: WooCommerce, premium plugins, custom theme or mu-plugins, multisite, PCI compliance requirements, or you lack staging access. The $1,000–$2,000 agency cost is insurance against a $12,000 weekend of lost sales (which one Chicago store experienced).

WordPress multisite — does PCC support it?

Yes. Scan per subsite; V+ for network rollup and centralized reports. MU-plugins and drop-ins (shared across the network) are included in scan scope. A New York agency managing 15-subsites used this workflow — see the case study above.

Conclusion — scan before you switch, no matter your US host

Hosts push PHP upgrades for your security and performance — not to white-screen your WooCommerce store during peak hours. When 35 plugins, a child theme, and three mu-plugins sit between you and PHP 8.3, you are not condemned to blind panel clicks or midnight backup restores.

The performance gains are real: 25–30% TTFB improvement, better Core Web Vitals, and up to 31% faster CPU-bound tasks via JIT. The risks are manageable: local static analysis catches known blockers at file + line level. The cost is predictable: $500–$2,500 depending on stack complexity — a fraction of a single weekend of lost ecommerce revenue.

It doesn't have to stay stressful. Inventory, local scan, fix errors, staging switch, runtime tests, 48 h watch — take back control of PHP migration whether you are on WP Engine, Kinsta, SiteGround, GoDaddy, or any US host.

Our final recommendation for 2026: this week, clone staging, install PHP Compatibility Checker, run the PHP 8.3 preset (or whatever target your host requires), export the JSON, fix the top errors, and switch PHP on staging before touching production. Go slow. Backup first. Document for next time.

If you run a US agency: bill PHP migration as a scoped project at $150–$250/h, deliver the JSON export and audit spreadsheet as client artifacts, and schedule quarterly rescans to catch compatibility drift before the next host deadline.

If you choose Volade: welcome. We built this because WordPress deserved an honest, local PHP compatibility tool — maintained, with presets and guardrails that agencies and merchants from Chicago to San Francisco can use without sending their code to a third-party API.

Happy migrating. Your stack will thank you.

---

Article updated July 13, 2026. Sources: PHPCompatibilityWP documentation, Volade field tests across 25 US-hosted WordPress sites, WP Engine/Kinsta/SiteGround/GoDaddy/Bluehost public documentation, WordPress Site Health guidelines, agency interviews: Chicago (Midwest WP), San Francisco (BayAreaWP), New York (NYCWP Freelance).