A droplet is whatever the person who built it made it. The first job of this migration is establishing what is actually running on yours.
You own the whole machine, which means the interesting parts of the migration are outside WordPress entirely.
A droplet might be a one-click image, a control panel like RunCloud or ServerPilot, or a hand-built LEMP stack. Each exports differently, so that gets established before anything is copied.
Backups, WP-CLI tasks and log rotation are frequently scheduled at the system level, where no WordPress export can see them. Those are read and recreated as platform jobs.
New certificates are issued here. Worth knowing: a droplet left running keeps attempting certbot renewals until the DNS change makes validation fail, and then it expires without telling anybody.
nginx, PHP-FPM and MySQL settings adjusted over the years are invisible to a site backup, so they are captured and applied here rather than silently reverting to defaults.
A single droplet often carries a staging copy, a side project or a mail relay somebody still depends on. That gets enumerated before anything is destroyed.
Not knowing how the server was set up is the normal case rather than an obstacle — often the person who built it has long since moved on.
A well-built droplet can be fast. The difference is that here the object cache, the edge and the PHP limits are configured and maintained without anybody having to log into a server.
These are the specific things a self-managed server migration needs, and nearly all of them sit outside WordPress.
| Setting | What we do | Why |
|---|---|---|
| Stack discovery | Web server, PHP handler and any control panel identified before the copy | A droplet might be a one-click image, ServerPilot, RunCloud or hand-built, and the export path differs for every one of them. |
| TLS certificates | Reissued here, with the old renewal retired deliberately | A certbot renewal on a decommissioned droplet keeps running until DNS validation fails, and then the certificate expires with nobody watching. |
| System cron | Read from crontab and recreated as platform jobs | Backups and WP-CLI tasks scheduled at system level are invisible to any WordPress export, and they are the thing most often discovered missing weeks later. |
| Server-level tuning | Captured from nginx, PHP-FPM and MySQL configuration and applied here | Anything adjusted on the box over the years exists nowhere in a site backup, so the migrated site would quietly revert to defaults. |
| Anything else on the droplet | Enumerated before the server is destroyed | One droplet often runs a staging copy, a side project or a mail relay that somebody downstream is still using. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, the whole stack inventoried first, and nothing destroyed until you say so.