Quick answer: Plan the move before touching anything: inventory what runs on the old machine, lower DNS TTLs a day ahead, take fresh backups, provision and test the new server, then switch traffic in a quiet window. Most migrations fail on forgotten crons, hardcoded IPs and skipped testing — not on the data copy.
Overview
A dedicated-server migration is a project with a checklist, whether you move to a bigger Cloud2Y machine, into another location, or from another provider. This article is the preparation phase; pair it with the copy/cutover steps for your specific stack.
Before you start
- Full inventory: sites, databases, services, cron jobs, mail, TLS certificates, firewall rules.
- Access to DNS management for every affected domain.
- A fresh, tested backup of everything.
- The new server ordered and reachable.
Step-by-step guide
- Inventory. List every service:
ss -tulpn,systemctl list-units --type=service --state=running,crontab -l(for each user), plus app configs. - Lower DNS TTLs to 300s for all records that will change — at least 24 h before cutover.
- Back up: databases dumped consistently, files rsync-ed off-server, configs archived.
- Prepare the target: same-or-newer OS, packages, users, firewall; copy data; run the stack on the new IP.
- Test on the new IP before DNS changes (hosts-file override on your workstation).
- Plan the cutover window: freeze content/db changes, final delta sync, switch DNS, monitor.
- Keep the old server running for a rollback period (days, not hours) before cancelling it.
Common issues
- Hardcoded IPs in app configs, firewalls and third-party allowlists — grep your configs for the old IP.
- Forgotten crons and queue workers — they silently stop doing their job after the move.
- Mail reputation — a new sending IP needs PTR/SPF/DKIM updates and warm-up.
- Big-bang cutover with no rollback — keep the old machine bootable until the new one has survived real traffic.
When to contact support
Tell us your migration window in advance — we can time extra IPs, PTR changes and hardware checks around it, and advise on moving between Cloud2Y locations.
Frequently asked questions
How far in advance should I lower DNS TTLs?
Lower the TTLs at least 24 hours before the cutover, to a value like 300 seconds. Old, long TTLs must expire first, otherwise visitors keep hitting the old server.
How long should I keep the old server?
Keep it for days rather than hours — until the new server has survived real production traffic, scheduled jobs and backups. It is your only instant rollback path.
What gets forgotten most often?
Cron jobs and queue workers, hardcoded IP addresses in configs and third-party allowlists, TLS certificates, and mail-related PTR, SPF and DKIM records.
Related articles
- How to migrate from VPS to a dedicated server
- How to order a dedicated server
- How dedicated server provisioning works
- How to contact Cloud2Y support
Need a hand? Contact Cloud2Y support →
