Dedicated Server Migration Checklist: How to Move Without Downtime

Migrating to a dedicated server is one of the best infrastructure decisions a growing business can make. It is also one of the easiest to get wrong.

Not because the process is technically impossible, but because most migrations are rushed, underprepared, or missing one critical step that only becomes obvious at 2am when the site is down and the DNS hasn’t propagated yet.

This checklist exists to prevent that. It covers every stage of a dedicated server migration, from the audit of your current environment to the monitoring checks you run in the days after the switch. Follow it in order, and you move without downtime, without data loss, and without surprises.

---

Before You Start: What This Migration Involves

A dedicated server migration is not just copying files from one machine to another. It involves:

• Auditing your current infrastructure and documenting everything that runs on it
• Choosing and provisioning the right dedicated server
• Replicating your environment on the new hardware
• Testing thoroughly before switching traffic
• Migrating DNS without causing downtime
• Monitoring the new environment in the days after the switch

Each stage has dependencies on the previous one. Skipping or rushing any step is where migrations go wrong. This checklist takes you through each one.

---

Phase 1 — Audit Your Current Infrastructure

The most common migration mistake is not knowing exactly what you are moving until you are already mid-migration. Before touching anything else, document your current environment completely.

✅ List every service running on your current server Web server (Apache, Nginx), database engine and version, application runtime (PHP version, Node.js, Python), mail services, cron jobs, background workers, monitoring agents. Everything.

✅ Document all configuration files nginx.conf, apache2.conf, php.ini, my.cnf or postgresql.conf, .env files, application config files. Back these up locally and to a separate storage location.

✅ Map all domains and subdomains Every domain pointing to this server, every subdomain, every DNS record. Export your full DNS zone file from your registrar or DNS provider.

✅ Record all software versions OS version and kernel, web server version, database version, runtime versions. The new server must match or be compatible with these. Version mismatches are the most common cause of post-migration application failures.

✅ Identify peak traffic windows Check your analytics or server logs for the times of lowest traffic. This is when you will perform the final switch. Never migrate during peak hours.

✅ Document all open ports and firewall rules List every port your applications use and every firewall rule currently in place. You will need to replicate this exactly on the new server.

---

Phase 2 — Choose and Provision Your New Dedicated Server

With your current environment fully documented, you now know exactly what you need from the new server.

✅ Match or exceed your current resource usage, with headroom Do not provision a server that exactly matches your current usage. Provision for where you will be in 12 months. If you currently use 8 cores and 32 GB RAM consistently, provision 16 cores and 64 GB.

✅ Choose the right storage type for your workload If your application is database-heavy or I/O intensive, NVMe storage is not optional, it is essential. SSDs are acceptable for lighter workloads. HDDs are only appropriate for cold storage or archival data.

✅ Confirm the datacenter location The new server should be geographically close to your primary user base. Changing datacenter regions during a migration can affect latency and SEO signals simultaneously, do not do both at once.

✅ Confirm OS compatibility The new server’s OS should match your current OS where possible, or be a version your applications are confirmed compatible with. Migrations are not the time for OS upgrades.

✅ Set up remote access immediately As soon as the server is provisioned, confirm SSH access works. Set up key-based authentication and disable password authentication before doing anything else.

---

Phase 3 — Back Up Everything Before You Touch Anything

This phase is non-negotiable. Every migration that has ever gone catastrophically wrong skipped or rushed this step.

✅ Create a full server backup of your current environment Use your existing backup tool or run a full snapshot if your current provider supports it. This is your safety net, if the migration fails at any point, you need to be able to restore to this state completely.

✅ Back up all databases separately Export every database as a .sql dump file. Store copies in at least two locations: your local machine and a cloud storage bucket or separate server. Verify the dump files are not corrupt by checking their size and spot-checking the contents.

✅ Back up all application files Use rsync or scp to transfer your application directory to the new server or to local storage. Confirm file counts and directory sizes match after transfer.

✅ Back up all configuration files These are often the most critical and most overlooked. Web server configs, database configs, application environment files, SSL certificates, and cron job definitions. Store them separately from the application files.

✅ Document your backup locations Write down exactly where every backup is stored and how to restore from each one. In a stressful migration scenario, you should not have to think about this.

---

Phase 4 — Configure the New Server

With backups confirmed and the new server provisioned, you now build the environment on the new hardware. This phase should be completed entirely before any traffic is switched.

Setting Up the Software Environment

✅ Install and configure the web server Install the same web server software (Apache or Nginx) and replicate your configuration files exactly. Test that the web server starts and serves a test page before proceeding.

✅ Install the runtime environment PHP, Node.js, Python, Ruby, whichever your application requires. Match the version exactly to your current environment. Version mismatches cause application failures that are often difficult to diagnose under pressure.

✅ Install and configure the database Install the same database engine and version. Import your database dumps. Verify row counts and data integrity after import.

✅ Deploy your application files Transfer your application to the new server. Set correct file permissions and ownership. Update any configuration files that contain IP addresses, hostnames, or paths that differ on the new server.

Security and Access Configuration

✅ Configure SSL certificates Install your SSL certificates on the new server. If using Let’s Encrypt, issue new certificates for the new server before the migration, they can be issued using DNS validation without the domain pointing to the new server yet.

✅ Replicate your firewall rules Configure ufw or iptables to match your current firewall rules exactly. Open only the ports your applications require and block everything else.

✅ Set up cron jobs Replicate every cron job from your current server. Check the cron syntax and confirm the paths are correct for the new server’s directory structure.

✅ Configure monitoring Install your monitoring agent (whether that is Datadog, Prometheus, Netdata, or another tool) before traffic arrives. You want baseline performance data from the moment the server goes live.

---

Phase 5 — Test Everything Before Switching

This is the phase that separates successful migrations from disastrous ones. Do not switch traffic until every item on this list passes.

Application and Database Testing

✅ Test the application using the server’s IP address Access your application directly via the new server’s IP address (or by editing your local /etc/hosts file to point your domain to the new IP). Verify every critical function works: login, checkout, form submissions, API calls, media uploads.

✅ Test database connectivity Run queries against the database from the application. Verify that read and write operations work correctly. Check that connection pooling is configured correctly.

✅ Test SSL Access the site over HTTPS using the IP address or hosts file method. Confirm there are no certificate errors and that HTTP redirects to HTTPS correctly.

✅ Test email sending If your application sends email, send test emails and confirm they are delivered and not flagged as spam. Check SPF, DKIM, and DMARC records are configured correctly on the new server.

Performance and Integration Testing

✅ Test cron jobs Trigger cron jobs manually and confirm they execute correctly with the correct permissions and paths.

✅ Run a performance baseline Use a load testing tool to simulate traffic on the new server and confirm it handles your expected peak load without performance degradation. This also gives you a baseline to compare against after the migration.

✅ Check all third-party integrations Payment gateways, CRM webhooks, analytics tracking, API connections to external services, test every integration that your application depends on.

---

Phase 6 — Migrate DNS Without Downtime

DNS migration is where most downtime happens, and where most of it can be avoided with the right preparation.

Preparing the DNS Switch

✅ Lower your TTL 24-48 hours before the migration DNS records have a TTL (Time To Live) that tells resolvers how long to cache the record. Lower this to 300 seconds (5 minutes) at least 24 hours before you plan to switch. This means DNS changes propagate globally in minutes rather than hours.

✅ Keep both servers running during the transition Do not decommission your old server the moment you update DNS. Keep it running and serving traffic for at least 24-48 hours after the switch. Some DNS resolvers will continue serving the old IP until their cache expires.

✅ Update the DNS A record to point to the new server IP Change the A record for your domain (and any subdomains) to the new server’s IP address. With a low TTL, this propagates quickly.

Managing Traffic During Propagation

✅ Monitor traffic on both servers during propagation Watch your web server logs on both the old and new server during the propagation window. Traffic will shift from old to new gradually as DNS caches expire globally. This is normal.

✅ Do a final database sync after DNS switch If your application writes data (orders, user registrations, form submissions), run a final database sync from old to new server in the hours after the DNS switch to capture any writes that went to the old server during propagation.

✅ Restore your TTL to normal after propagation is complete Once all traffic has moved to the new server and you are confident the migration is stable, restore your DNS TTL to its normal value (typically 3600 seconds).

---

Phase 7 — Monitor and Validate After the Switch

The migration is not complete when DNS propagates. It is complete when you have confirmed the new server is stable under real production traffic.

✅ Monitor CPU, RAM, and disk I/O for the first 48 hours Compare these metrics against your baseline from the old server. Unexpected spikes indicate configuration issues or workload differences that need attention.

✅ Monitor error logs continuously Watch your web server error logs and application logs closely for the first 48-72 hours. Errors that did not exist on the old server indicate environment differences that testing missed.

✅ Monitor uptime with an external tool Use an uptime monitoring service (UptimeRobot, Better Uptime, or equivalent) to alert you immediately if the new server becomes unreachable. External monitoring catches issues your internal tools might miss.

✅ Check your Google Search Console After 48 hours, check Search Console for any crawl errors or coverage issues. A successful migration should not affect your search rankings, but any configuration errors (incorrect redirects, SSL issues, blocked resources) will appear here quickly.

✅ Confirm backups are running on the new server Verify that your automated backup schedule is running correctly on the new server. Do not discover your backup process is broken during a future incident.

✅ Decommission the old server only after 72+ hours of stable operation Keep the old server available as a fallback for at least 72 hours after the migration. Only decommission it once you are fully confident the new environment is stable.

---

The Complete Migration Checklist at a Glance

Phase 1 — Audit

✅ List all services · ✅ Document all configs · ✅ Map all domains and DNS · ✅ Record software versions · ✅ Identify low-traffic windows · ✅ Document firewall rules

Phase 2 — Provision

✅ Right specs with headroom · ✅ Correct storage type · ✅ Confirmed datacenter location · ✅ OS compatibility confirmed · ✅ SSH access configured

Phase 3 — Backup

✅ Full server backup · ✅ Database dumps verified · ✅ Application files backed up · ✅ Config files backed up · ✅ Backup locations documented

Phase 4 — Configure

✅ Web server installed and configured · ✅ Runtime environment matched · ✅ Database installed and data imported · ✅ Application deployed · ✅ SSL configured · ✅ Firewall rules replicated · ✅ Cron jobs set up · ✅ Monitoring installed

Phase 5 — Test

✅ Application tested via IP · ✅ Database connectivity confirmed · ✅ SSL verified · ✅ Email sending tested · ✅ Cron jobs verified · ✅ Performance baseline run · ✅ Third-party integrations tested

Phase 6 — DNS

✅ TTL lowered 24-48h before · ✅ Both servers kept running · ✅ A record updated · ✅ Traffic monitored on both servers · ✅ Final database sync completed · ✅ TTL restored

Phase 7 — Monitor

✅ CPU/RAM/disk monitored 48h · ✅ Error logs monitored 72h · ✅ External uptime monitoring active · ✅ Search Console checked · ✅ Backups confirmed running · ✅ Old server decommissioned after 72h

---

---

Frequently Asked Questions

FAQ 1 :: How long does a dedicated server migration typically take?

---

FAQ 2 :: Can I migrate to a dedicated server without any downtime?

---

FAQ 3 :: What is the biggest risk during a dedicated server migration?

---

FAQ 4 :: How do I handle database writes during DNS propagation?

---

FAQ 5 :: Should I upgrade my OS or software versions during the migration?

---

FAQ 6 :: How do I choose the right dedicated server for my migrated workload?