Quick answer: With root access on both sides, VPS-to-VPS migration is the cleanest kind: provision a Cloud2Y VPS with a matching or newer OS, copy data with rsync over SSH, dump and import databases, replicate your config, test via hosts file, then switch DNS. Most single-server setups move in an evening.
Overview
Because you control both servers, you can automate almost everything and repeat the sync as many times as you like before the cutover. The pattern below — full copy, then delta syncs, then a short freeze — is the same one used for zero-downtime migrations of any size.
Before you start
- Root SSH access to the old VPS and your new Cloud2Y VPS.
- An inventory of services: web server, database, PHP/runtime versions, cron jobs, TLS certificates.
- Enough disk on the target for your data plus headroom.
Step-by-step guide
- Prepare the target: install the same stack and versions on the Cloud2Y VPS; copy relevant config files (nginx sites, php-fpm pools, systemd units).
- First data copy: from the old server run:
rsync -aHz --info=progress2 /var/www/ user@NEW_IP:/var/www/ - Databases: dump on the old server, import on the new — see migrating databases for large-size strategies.
- Repeat rsync close to the cutover: only changed files transfer, so delta runs take minutes.
- Test the site on the new IP with a hosts-file override (guide).
- Cutover: brief write freeze, final rsync + database delta, switch DNS, monitor logs on the new server.
Common issues
- Copying system directories: never rsync
/etcor/wholesale between servers — move data and re-create config deliberately. - Divergent package versions: pin or match versions first; "it worked on the old box" is usually a version story.
- Firewall on the new server: remember to open 80/443 before testing — a timeout is often just the firewall.
When to contact support
If the source provider limits SSH, your setup spans multiple servers, or you simply want it done for you, request a free migration and include both servers' details.
Frequently asked questions
Can I copy the whole old server disk to the new VPS?
Cloning system directories between different providers usually breaks networking and boot config. Move your data and re-create configuration deliberately — it is faster to debug and cleaner long-term.
Why run rsync more than once during a migration?
The first run copies everything; each following run transfers only files changed since. That makes the final sync during the cutover freeze take minutes even for large sites.
Do my software versions have to match exactly?
Match major versions of PHP, the database and the web server first so the site behaves identically, then upgrade on the new server as a separate, controlled step after the move.
Related articles
- How to migrate from HostPro to Cloud2Y
- How to migrate from Contabo to Cloud2Y
- How to migrate from Hetzner to Cloud2Y
- How to avoid downtime during migration
Ready to move? Order a VPS at Cloud2Y →
