Managed WordPress hosting for sites on a DigitalOcean droplet.
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.
What a droplet holds that no WordPress export can see.
You own the whole machine, which means the interesting parts of the migration are outside WordPress entirely.
Whatever stack is actually there
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.
Cron living in crontab
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.
Certificates retired properly
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.
Server tuning nobody wrote down
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.
Everything else on the box
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.
Find out what is there, then move it.
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.
- Stack and control panel identified before the export
- Crontab and server config captured
- Cutover at a time you choose
- Droplet left running until you confirm
The tuning, without the maintenance.
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.
What we change when a site arrives from a droplet
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. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
I do not know how my droplet was set up. Is that a problem?
What happens to my Let's Encrypt certificate?
I have cron jobs on the server. Will you find them?
Can I keep root access after moving?
When should I destroy the droplet?
Hand the server back and keep the performance.
Free migration, the whole stack inventoried first, and nothing destroyed until you say so.