Shared hosting can run WordPress securely when accounts are isolated and the provider offers useful controls. It becomes a cleanup obstacle when investigators cannot preserve logs, identify writers, inspect every site or prevent neighbouring paths from restoring malware.
Migration is not a substitute for cleaning. Moving infected files to a new host simply relocates the incident.
Identify evidence limitations
Record which web/PHP/authentication/file-change logs are available, their retention and whether timestamps cover reinfection.
If the provider cannot identify SFTP/panel activity or preserve quarantined files, state that attribution is limited. Missing evidence does not prove the server is compromised, but it lowers confidence.
Ask the host what it can inspect at the system level.
Test account isolation
Map document roots, filesystem owners, database users and FTP accounts. Determine whether one WordPress site can write another site’s files.
Do not perform destructive cross-site tests. Use provider documentation or harmless authorised permissions checks.
Addon domains nested under one writable public_html may share a larger blast radius than expected.
Review recovery controls
A viable cleanup needs filesystem/database export, recovery access while public execution is restricted, targeted cache purge and a way to replace trusted packages.
If the only options are “reactivate everything” or “restore an unverified backup,” reliable work is difficult. Request a quarantine or temporary recovery environment.
Confirm credentials and sessions can be revoked individually.
Consider resource and operational constraints
Large scans, archive extraction and hash comparison may hit CPU/I/O/inode limits. Do not weaken detection or leave public malware because the account cannot finish a scan.
Ask whether the host can create a server-side snapshot or move the account into temporary isolation.
Repeated suspensions without an explanation waste the evidence window.
Decide whether migration improves the boundary
Migration is justified when isolation cannot be corrected, provider logs/control are inadequate, several critical sites share one account or the host cannot support patched PHP/components.
Choose a destination with separate site users, current PHP, backups outside web roots, useful logs and controlled staging.
Do not decide based only on advertised CPU/storage.
Define exit criteria before moving
Write down what the new environment must prove: clean package/database review, distinct credentials, patched PHP/components, working logs, isolated staging, tested backups and no recurrence across the historical window.
Set a rollback window and decide who can change DNS, CDN and mail. Without exit criteria, migration can become an emergency copy of unknown files followed by premature cancellation of the only evidence source.
Keep the old host restricted and non-processing until logs/evidence are retained and the new site passes business/security checks.
Build clean before moving
Preserve the source, analyse offline, rebuild core/plugins/themes from verified packages, review custom code and clean database/users/cron.
Rotate credentials and remove abandoned sites. Import only reviewed uploads/content.
Keep the new environment private until recurrence tests and business flows pass.
Prevent dual processing
During DNS propagation, old and new sites can both run cron, send email or accept orders. Disable side effects on the old environment and use sandbox/test controls.
Maintain a rollback without allowing the old compromised site to regain public traffic.
Verify DNS, SSL, CDN and mail records after cutover.
Prove the new environment is clean
Monitor hashes, users, schedules, authentication and outbound requests beyond the old recurrence interval. Test forms, email and authorised checkout.
Review it again after the first update.
Request a cleanup/migration assessment when the current host cannot establish a trustworthy boundary. Send limitations and site inventory, not credentials.
The correct decision is evidence-led: clean first, migrate to improve control, then prove that reinfection did not follow.