RunCloud is a control panel on a server you rent and own. Moving is less a migration than a change in who is accountable when the kernel needs patching at two in the morning.
RunCloud configured Nginx, PHP-FPM and cron on your VPS. The configuration comes across; the ownership of the machine does not come with it.
A panel tells you an update is available. Somebody still has to apply it, test it and be awake if it goes wrong. Here that is not a task on your side at all.
Custom location blocks, rate limits and rewrite rules accumulate in a panel over years. We read them and reproduce the behaviour rather than assuming the defaults were never touched.
RunCloud typically runs wp-cron from system cron. That is the right decision, and it needs to be recreated here rather than silently reverting to visitor-triggered cron.
Buffer pool and connection limits on a self-managed box are sized to that box. Carried across unexamined they are either wasteful or a bottleneck.
Panels encourage several sites on one server sharing PHP workers. Separating them is usually the largest single performance change of the move.
Files and database are the easy half. The half that breaks sites is everything RunCloud was doing outside the WordPress install.
The common RunCloud setup puts several sites on one VPS sharing PHP workers, so the busiest one sets the response time for all of them.
These differ from a standard WordPress site on the same plan, and each follows from where a panel-managed VPS leaves things.
| Setting | What we do | Why |
|---|---|---|
| Nginx customisations | Inventoried from the panel and reproduced explicitly | Location blocks and rewrite rules added to a panel over several years are invisible in a file-and-database copy, and the site behaves differently the moment they are gone. |
| Cron source | Platform scheduler, with WP-Cron left disabled as it already was | A panel-managed server usually runs wp-cron from system cron, so a migration that quietly re-enables visitor-triggered cron makes scheduled work unreliable for the first time in years. |
| Worker allocation | One pool per site instead of one pool shared by all sites | Several sites on one VPS share a PHP-FPM pool, which means the busiest of them determines how slow the quietest one feels. |
| Database sizing | Re-derived from the workload rather than carried from the old VPS | Buffer pool and connection settings on a self-managed box were sized to that box's memory, so importing them either wastes capacity or throttles the site. |
| Operating system responsibility | Transferred entirely rather than notified | A control panel surfaces the update and still leaves a person accountable for applying it, which is the actual cost of self-management people underestimate. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, your Nginx behaviour reproduced, and nobody on your side paged for a kernel update.