In short: If you want to switch hosting providers after a security incident, first secure evidence and clarify the incident, then transfer only checked data to a freshly set up system, and end the old contract only afterward. Choose the new provider by security criteria: demonstrable patch processes, separation of customers, access to logs, backups and clear contacts. Switching hosts makes sense when trust or performance is lacking, but it does not replace cleanup.
When trust is gone
After PHP2Shell, many companies experienced their hoster under pressure for the first time. Some quickly got a clear answer about the patch status. Others waited days for a reply, received only generic phrases, or found that their website was running on an outdated PHP version. If an incident follows on top of that, the wish to switch is understandable.
However, switching hosts is not a step in handling the incident, but in rebuilding afterward. Done in the wrong order, it can mean taking the attacker along and, at the same time, losing the traces that show what happened.
The right order when switching
- Secure traces while they exist. Logs, files and database of the old system belong in a backup before anything is deleted or terminated. Explicitly ask the old hoster for access and error logs from 20 October 2026 onward and for their retention period. How to proceed is described in the article Securing evidence before you reinstall.
- Contain the incident. Which systems are affected, which accesses were used, which data was reachable? Notification duties and the question of what you may take with you depend on this.
- Check notification duties. If personal data may be affected, the deadline for a possible GDPR notification starts when you become aware of the incident, not with the move. Background is at GDPR notification duty: 72 hours.
- Build the new system cleanly. Supported PHP version, current packages, hardened configuration, before the first file is transferred.
- Transfer only what has been checked. Code from a clean source, database and media after review.
- Change all credentials. Database, admin accounts, SSH, FTP, API keys, including those in configuration files.
- Switch over and observe. DNS change, then closer monitoring for a while.
- End the old contract. Only once logs and backups are secured and the new operation runs stably.
Do not terminate the old contract before you have logs and backups in hand. When the contract ends, data may be deleted at the provider that you need for insurers, authorities or your own investigation.
What you should not take with you
It would be convenient to simply copy the complete web directory or an image of the server. After an incident, that is exactly what is risky. Webshells disguise themselves as harmless files, backdoors hide in configuration files such as .htaccess or .user.ini, and injected code can sit in database content.
Transfer the application code from a clean source instead, such as the vendor package in the matching version or your version control system. Take media without executable files, and the database after a check for conspicuous content and new administrator accounts. What was found on the old system helps with this check.
Also think of everything that sits next to the website at the old provider. Mailboxes, DNS records, certificates and forwards are easily forgotten during a move. Lower the validity period (TTL) of the DNS records a few days before switching so that the change reaches visitors quickly. If email moves along, plan the mailbox migration separately, because credentials there can also be affected after an incident.
Choosing the new hoster by security
Price and storage space are in every offer. The decisive security questions you usually have to ask yourself. The following list helps with comparison:
| Criterion | Question to the provider | Why it matters |
|---|---|---|
| Patch process | How and within what framework are PHP security updates applied and restarted? | PHP2Shell showed how important a demonstrable process is |
| Proof | Do I receive written confirmation of the patch status on request? | Basis for your own documentation |
| PHP versions | Which branches are offered, and for how much longer? | Old branches without updates are a permanent risk |
| Separation | Does each website run with its own user and its own PHP process? | Limits damage if a neighbor is attacked |
| Logs | Do I have access to access and error logs, and how long are they kept? | Without logs, no investigation |
| Backups | How often, how long, separate from the web server, with a restore test? | Recovery after an incident |
| Emergency contact | How do I reach a qualified person during an incident? | Time is the scarcest factor in an emergency |
| Data processing | Is there a contract under the GDPR and a list of sub-processors? | Mandatory for personal data |
A template for the question about the patch status is provided by the guide Asking your hoster for the patch status. It is also suitable for comparing providers before signing a contract.
Is a different operating model the better answer?
Sometimes the problem lies less with the hoster than with the operating model. Anyone running their own server without regular maintenance is often better off with a well-supported managed offer. Conversely, a company with its own IT can gain more control over patch timing by managing things itself. The trade-off is described in the article Managed hosting or your own server?.
Whatever the model, keep the division of tasks in writing. Who applies PHP updates, who restarts, who checks the application, who contacts whom in an emergency? With PHP2Shell, many delays arose exactly at this point, because each side thought the other was taking care of it.
How does PHP SOS help?
- We secure logs and data of the old system and clarify what happened in the incident.
- We build the new system hardened and transfer only checked content from clean sources.
- We review offers from new providers against the security criteria and ask the right questions.
- For an ongoing incident, we work within our incident response until the incident is closed and documented.
Frequently asked questions
Should I switch hosting providers immediately after a hack?
Not immediately. First, traces must be secured, the incident contained and the cause clarified. A rushed move may carry malicious code along and can destroy evidence at the old provider.
Was the hoster to blame if my website was attacked via PHP2Shell?
That depends on the contract and on the timing. With shared hosting, the hoster is usually responsible for PHP updates; with your own servers, the operator is. The patches appeared on 21 October 2026; whether and when they were applied can only be clarified with evidence. For liability questions, seek legal advice.
Which data may I take to the new hoster?
Only checked content: the database after a check for injected code, media without executable files, and code from a clean source such as the vendor package or your version control system. Do not transfer complete server images or web directories from the compromised system without checking them.
Do I have to involve data protection after an incident?
If personal data may be affected, a notification duty under the GDPR may apply, as a rule within 72 hours. At the new hoster you also need a data processing agreement. Clarify this with your data protection officer; this is not legal advice.