Recovery often leaves WordPress, PHP or extensions needing updates that cannot be delayed indefinitely. Updating everything at once makes any failure difficult to diagnose and can restore unreviewed packages from old deployment sources.
Establish a trusted baseline, then change small dependency groups with rollback and business tests.
Confirm recovery baseline
Record clean release identifier, component inventory, PHP/database versions, custom code owners, removed vulnerabilities and known-good backup. Ensure original indicators remain absent.
Do not begin routine updates while unexplained administrators, cron or file changes continue. Recovery must have an accepted evidence matrix.
Keep infected archives separate.
Create a tested backup
Back up filesystem/database/configuration outside public roots and restore it into isolation to prove usability. Protect customer/order data and record timestamp/checksum.
A backup success email is not restore proof. Do not overwrite incident evidence or the only clean snapshot.
Define rollback that returns to the accepted clean release.
Reproduce production safely
Use a protected staging environment with sanitised data, separate secrets and no live SMTP/payment/webhooks. Match PHP/database/cache and relevant hosting configuration.
Do not clone production secrets or customer database into a public staging domain. Ensure staging cannot deploy automatically to live.
Test at the canonical hostname through a controlled mapping where needed.
Read compatibility requirements
Check WordPress, WooCommerce, PHP and each critical plugin/theme release notes and supported versions. Include payment, membership, form, cache, security and custom code.
Replace abandoned components rather than holding the whole site on insecure versions. Obtain current trusted packages/licences.
Record database migrations and downgrade limitations.
Plan database migrations
WooCommerce and extensions may run irreversible or long database updates. Record schema/data versions, Action Scheduler state and downgrade support before production.
Take a fresh database snapshot immediately before migration and pause writes. Test migration duration and post-migration queue on staging.
Do not roll back files alone after schema changes; restore compatible files/database together or use the vendor’s supported forward repair.
Sequence changes
Update one related group at a time: PHP/runtime where appropriate, WordPress core, WooCommerce, critical extensions, theme/custom compatibility. The exact order depends on supported matrices.
Test after each group and preserve logs. Do not activate an unknown package merely because update metadata offers it.
Keep automatic updates deliberate for business-critical components.
Plan production maintenance
Schedule a low-risk window, pause checkout/writes where database migrations could occur and inform operational owners. Keep a static maintenance/fallback route.
Prevent two application versions from writing the same database. Record start, changes and rollback decision time.
Do not use production customers as the first test.
Revalidate security and edge controls
Updates can change REST/AJAX paths, script handles and webhook behaviour. Verify Cloudflare/WAF/cache/CSP/consent rules do not block or weaken the new version.
Check administrators, file/config differences and new scheduled tasks created by migration. Confirm the package did not enable telemetry/external access outside approved policy.
Keep the original incident indicators in the regression set.
Verify business-critical paths
Test login/reset, forms, checkout sandbox/approved test, payments/webhooks, orders/stock/refunds, cron, transactional mail, uploads, mobile/languages and analytics.
Inspect PHP/JS errors and scheduled-action backlog. Re-run original incident conditions and security checks.
Label and remove synthetic data.
Roll back carefully
If a failure appears, stop writes and revert files/database together when a migration changed schema. A file-only downgrade against upgraded tables can cause more damage.
Document the failed version and evidence; do not keep repeatedly toggling production. Repair on staging or replace the component.
Rollback must not restore the vulnerable pre-recovery release.
Monitor after release
Watch errors, file changes, administrators, cron, mail and business conversions through the next normal cycle. Confirm backups/deployments contain the updated clean state.
Request recurring update care when custom WooCommerce dependencies make releases high risk. Share inventory and test results—never credentials, licence keys, backups or customer data publicly.