{"id":9886,"date":"2026-10-08T21:09:14","date_gmt":"2026-10-09T02:09:14","guid":{"rendered":"https:\/\/www.serverpronto.com\/spu\/2026\/10\/dedicated-server-migration-checklist-for-agencies\/"},"modified":"2026-10-08T21:09:16","modified_gmt":"2026-10-09T02:09:16","slug":"dedicated-server-migration-checklist-for-agencies","status":"publish","type":"post","link":"https:\/\/www.serverpronto.com\/spu\/2026\/10\/dedicated-server-migration-checklist-for-agencies\/","title":{"rendered":"Dedicated Server Migration Checklist for Agencies"},"content":{"rendered":"<h2 id=\"table-of-contents\">Table of Contents<\/h2>\n<ul>\n<li><a href=\"#dedicated-server-migration-checklist-for-agencies-what-youll-need-before-you-start\">Dedicated Server Migration Checklist for Agencies: What You&#8217;ll Need Before You Start<\/a>\n<ul>\n<li><a href=\"#inventory-and-access-audit\">Inventory and access audit<\/a><\/li>\n<li><a href=\"#roles-and-rollback-budget\">Roles and rollback budget<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#build-a-server-migration-plan-template-your-team-can-reuse\">Build a Server Migration Plan Template Your Team Can Reuse<\/a>\n<ul>\n<li><a href=\"#the-seven-fields-every-migration-plan-needs\">The seven fields every migration plan needs<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#step-1-provision-and-harden-the-new-dedicated-server\">Step 1: Provision and Harden the New Dedicated Server<\/a><\/li>\n<li><a href=\"#step-2-replicate-data-apps-and-email-without-breaking-anything\">Step 2: Replicate Data, Apps, and Email Without Breaking Anything<\/a><\/li>\n<li><a href=\"#step-3-run-a-dns-cutover-checklist-with-a-tested-rollback-path\">Step 3: Run a DNS Cutover Checklist With a Tested Rollback Path<\/a>\n<ul>\n<li><a href=\"#translate-your-ttl-into-a-real-downtime-allowance\">Translate your TTL into a real downtime allowance<\/a><\/li>\n<li><a href=\"#match-the-cutover-to-your-sla-scope\">Match the cutover to your SLA scope<\/a><\/li>\n<li><a href=\"#before-cutover\">Before cutover<\/a><\/li>\n<li><a href=\"#during-cutover\">During cutover<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#step-4-control-website-migration-downtime-with-a-maintenance-window\">Step 4: Control Website Migration Downtime With a Maintenance Window<\/a><\/li>\n<li><a href=\"#step-5-run-post-migration-website-checks-before-you-tell-the-client\">Step 5: Run Post-Migration Website Checks Before You Tell the Client<\/a>\n<ul>\n<li><a href=\"#run-the-functional-checklist-on-every-site\">Run the functional checklist on every site<\/a><\/li>\n<li><a href=\"#verify-uptime-independently-not-just-from-the-providers-dashboard\">Verify uptime independently, not just from the provider&#8217;s dashboard<\/a><\/li>\n<li><a href=\"#know-how-to-claim-an-uptime-credit\">Know how to claim an uptime credit<\/a><\/li>\n<li><a href=\"#distinguish-the-failure-types-before-you-escalate\">Distinguish the failure types before you escalate<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"#common-mistakes-agencies-make-during-a-dedicated-server-migration\">Common Mistakes Agencies Make During a Dedicated Server Migration<\/a><\/li>\n<li><a href=\"#frequently-asked-questions\">Frequently Asked Questions<\/a><\/li>\n<\/ul>\n<p><em>Last Updated: October 8, 2026<\/em><\/p>\n<h2 id=\"dedicated-server-migration-checklist-for-agencies-what-youll-need-before-you-start\">Dedicated Server Migration Checklist for Agencies: What You&#8217;ll Need Before You Start<\/h2>\n<p>A <a href=\"\/spu\/2026\/10\/dedicated-server-uptime-guarantee-explained\/\">dedicated server<\/a> migration checklist for agencies exists because client work cannot pause while infrastructure moves.<\/p>\n<p>Most migration failures trace back to missing preparation, not bad hardware. An agency moving 15 client sites needs a written plan, named owners, and a rollback budget before touching anything.<\/p>\n<p>Below, we break the process into five steps, from inventory through post-migration checks, plus the mistakes that cause the most damage.<\/p>\n<h3 id=\"inventory-and-access-audit\">Inventory and access audit<\/h3>\n<p>Start by listing everything that must move. Skip this and you will discover a forgotten client database mid-cutover.<\/p>\n<p>Build a spreadsheet covering:<\/p>\n<ul>\n<li>Every domain, subdomain, and DNS zone you manage<\/li>\n<li>Applications, databases, and their versions<\/li>\n<li>Mailboxes, forwarders, and MX records<\/li>\n<li>SSL certificates and renewal dates<\/li>\n<li>Cron jobs, scheduled tasks, and third-party integrations<\/li>\n<li>Credentials: registrar logins, DNS panel access, API keys<\/li>\n<\/ul>\n<p>Note which services are mission-critical hosting versus nice-to-have. That ranking drives your maintenance window later.<\/p>\n<h3 id=\"roles-and-rollback-budget\">Roles and rollback budget<\/h3>\n<p>Name a migration lead, a DNS owner, and a client communications owner. One person cannot hold all three roles during a live cutover.<\/p>\n<p>Set a rollback budget too: a written time limit for how long you will troubleshoot before reverting. Many agencies find that a fixed cutoff keeps a two-hour window from becoming an eight-hour outage.<\/p>\n<div style=\"margin:1.5rem 0;padding:16px 20px;background-color:#f0f9ff;border-left:4px solid #bae6fd;border-radius:0 8px 8px 0\">\n<strong style=\"display:block;margin-bottom:4px;color:#111827;font-size:14px\"> Pro Tip<\/strong><br \/>\n<span style=\"color:#374151;font-size:15px;line-height:1.6\">Assign a &#8220;scribe&#8221; who logs every command and timestamp during cutover. When something breaks, the log tells you exactly which change caused it, instead of forcing a rebuild from memory.<\/span>\n<\/div>\n<h2 id=\"build-a-server-migration-plan-template-your-team-can-reuse\">Build a Server Migration Plan Template Your Team Can Reuse<\/h2>\n<p>A server migration plan template is a fixed document that captures scope, owners, timing, and rollback rules for every move, so no agency engineer starts from a blank page. Standardizing it cuts prep time on repeat migrations.<\/p>\n<h3 id=\"the-seven-fields-every-migration-plan-needs\">The seven fields every migration plan needs<\/h3>\n<table style=\"width:100%;border-collapse:collapse;margin:2rem 0;font-size:14px;line-height:1.6\">\n<thead style=\"background-color:#f8f9fa;color:#111827;padding:12px 16px;text-align:left;font-weight:600;border-bottom:2px solid #e5e7eb\">\n<tr>\n<th style=\"background-color:#f8f9fa;color:#111827;padding:12px 16px;text-align:left;font-weight:600;border-bottom:2px solid #e5e7eb\">Field<\/th>\n<th style=\"background-color:#f8f9fa;color:#111827;padding:12px 16px;text-align:left;font-weight:600;border-bottom:2px solid #e5e7eb\">What to Record<\/th>\n<th style=\"background-color:#f8f9fa;color:#111827;padding:12px 16px;text-align:left;font-weight:600;border-bottom:2px solid #e5e7eb\">Why It Matters<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Scope<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Domains, apps, databases, mail<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Prevents forgotten assets<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Owners<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Lead, DNS, comms, scribe<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Clear accountability<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Timeline<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Prep, cutover, verification dates<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Sets client expectations<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Maintenance window<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Start and end time<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Controls website migration downtime<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Rollback trigger<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Time limit and failure conditions<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Stops open-ended outages<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Verification list<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Checks per site and service<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Catches silent breakage<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Communication plan<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Who tells clients what, when<\/td>\n<td style=\"padding:12px 16px;border-bottom:1px solid #e5e7eb\">Protects the relationship<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Fill every field before provisioning. A template with blanks is a plan with holes.<\/p>\n<h2 id=\"step-1-provision-and-harden-the-new-dedicated-server\">Step 1: Provision and Harden the New Dedicated Server<\/h2>\n<p>Provisioning should happen days before cutover, never the same morning. ServerPronto provisions dedicated servers in about two hours, which gives your team room to configure and test without clock pressure.<\/p>\n<p>Work through this sequence:<\/p>\n<ol>\n<li>Confirm the OS image, kernel version, and control panel match the old environment<\/li>\n<li>Apply updates and configure the firewall before any data lands<\/li>\n<li>Set up SSH keys, disable password login, and create service accounts<\/li>\n<li>Install monitoring and log shipping<\/li>\n<li>Verify root access works for every tool your team needs<\/li>\n<\/ol>\n<p>Full root access matters here. If you rely on <a href=\"\/spu\/2026\/10\/how-to-deploy-custom-database-modules\/\">custom database modules<\/a> or specific software builds, confirm you can install them without a support ticket.<\/p>\n<div style=\"margin:1.5rem 0;padding:16px 20px;background-color:#fffbeb;border-left:4px solid #fde68a;border-radius:0 8px 8px 0\">\n<strong style=\"display:block;margin-bottom:4px;color:#111827;font-size:14px\"> Watch Out<\/strong><br \/>\n<span style=\"color:#374151;font-size:15px;line-height:1.6\">Skipping the hardening pass because &#8220;the old server was never attacked&#8221; is the mistake that bites hardest. An unpatched, internet-facing server can be compromised within hours of going live.<\/span>\n<\/div>\n<h2 id=\"step-2-replicate-data-apps-and-email-without-breaking-anything\">Step 2: Replicate Data, Apps, and Email Without Breaking Anything<\/h2>\n<p>Replication is where quiet errors hide. A database that copies cleanly can still fail on permissions, character sets, or scheduled jobs.<\/p>\n<p>Move in this order:<\/p>\n<ul>\n<li>Databases first, using a dump and restore, then verify row counts and a sample of records<\/li>\n<li>Application files and configuration, checking file ownership and paths<\/li>\n<li>Email accounts and mailboxes, testing send and receive before cutover<\/li>\n<li>Cron jobs and integrations, retargeting any hardcoded IP addresses<\/li>\n<\/ul>\n<p>Run the application on the new server using a hosts-file override. This lets you test the full stack before DNS changes anything for real visitors.<\/p>\n<p>For agencies running <a href=\"\/spu\/2026\/09\/reliable-dedicated-server-for-database-applications\/\">database-driven campaigns<\/a> or AI workloads, confirm the new hardware handles peak load. A staging test at half traffic tells you little.<\/p>\n<h2 id=\"step-3-run-a-dns-cutover-checklist-with-a-tested-rollback-path\">Step 3: Run a DNS Cutover Checklist With a Tested Rollback Path<\/h2>\n<p>A DNS cutover checklist is the ordered list of DNS changes, verifications, and rollback actions that governs the moment traffic moves. Treat it as a script, not a guideline.<\/p>\n<figure class=\"article-content-image my-8\" style=\"margin:2em 0;padding:0;background:transparent;border:0\"><img decoding=\"async\" src=\"https:\/\/cdn.grandranker.com\/articles\/dedicated-server-migration-checklist-for-agencies-content-1-1791500644.jpg\" alt=\"Agency engineer at a desk with two monitors showing DNS records and server status dashboards, notebook with a handwritten cutover checklist beside the keyboard\" class=\"w-full rounded-lg shadow-lg\" loading=\"lazy\" style=\"display:block;width:100%;max-width:100%;height:auto;border-radius:8px;margin:0 auto\"><figcaption class=\"text-sm text-gray-600 mt-2 text-center\" style=\"font-size:0.875em;color:inherit;opacity:0.75;text-align:center;margin-top:0.6em\">Agency engineer at a desk with two monitors showing DNS records and server status dashboards, notebook with a handwritten cutover checklist beside the keyboard<\/figcaption><\/figure>\n<h3 id=\"translate-your-ttl-into-a-real-downtime-allowance\">Translate your TTL into a real downtime allowance<\/h3>\n<p>TTL is the number that decides how long stale records can keep pointing visitors at the old server. A 3,600-second TTL means resolvers may cache the old address for up to an hour after you publish the change. A 300-second TTL caps that exposure at five minutes.<\/p>\n<p>A common pattern is to drop TTLs to 300 seconds two days out, confirm propagation with a public DNS lookup tool from several regions, then raise them back to a normal value a week after cutover.<\/p>\n<h3 id=\"match-the-cutover-to-your-sla-scope\">Match the cutover to your SLA scope<\/h3>\n<p>An uptime percentage alone does not tell you what is covered. Before you schedule the window, read the dedicated-server agreement and separate four things:<\/p>\n<p class=\"cta-inline\" style=\"background-color: #2563eb08;border-left: 4px solid #2563eb;padding: 16px 20px;margin: 24px 0;border-radius: 0 8px 8px 0\">\n     <a href=\"https:\/\/www.serverpronto.com\/\" style=\"color: #2563eb;font-weight: 600;text-decoration: underline\">Build &amp; Price ?<\/a>\n<\/p>\n<ul>\n<li><strong>Network availability<\/strong>, whether the guarantee covers the provider&#8217;s transit and routing, or only the server&#8217;s power and hardware.<\/li>\n<li><strong>Power and hardware<\/strong>, whether a failed disk or PSU counts as downtime, and how fast replacement is promised.<\/li>\n<li><strong>Maintenance windows<\/strong>, whether scheduled work is excluded from the calculation, and how much notice the provider must give.<\/li>\n<li><strong>Measurement boundaries<\/strong>, whether the clock runs from the provider&#8217;s monitoring point or from your users&#8217; location.<\/li>\n<\/ul>\n<p>Most practitioners find the exclusions matter more than the headline number. A guarantee that excludes scheduled maintenance and measures only the provider&#8217;s internal network is a different promise than one that covers the full service path.<\/p>\n<h3 id=\"before-cutover\">Before cutover<\/h3>\n<ul>\n<li>Lower TTL values on all records at least 24 hours ahead<\/li>\n<li>Record current DNS values in writing, including the registrar and zone file<\/li>\n<li>Confirm the rollback path works by reverting one low-traffic domain first<\/li>\n<li>Notify clients of the maintenance window and the expected duration<\/li>\n<li>Confirm the old server stays powered, reachable, and licensed through the window<\/li>\n<\/ul>\n<h3 id=\"during-cutover\">During cutover<\/h3>\n<p>Change records in small batches, verify each one, and keep the old server running and reachable. Verify from more than one network, a resolver in one region can serve a stale answer while another has already updated. If verification fails past your rollback trigger, revert immediately rather than troubleshooting live.<\/p>\n<div style=\"margin:1.5rem 0;padding:16px 20px;background-color:#f0fdf4;border-left:4px solid #bbf7d0;border-radius:0 8px 8px 0\">\n<strong style=\"display:block;margin-bottom:4px;color:#111827;font-size:14px\"> Key Takeaway<\/strong><br \/>\n<span style=\"color:#374151;font-size:15px;line-height:1.6\">The old server stays live until every site passes verification. Decommissioning early removes your only safety net.<\/span>\n<\/div>\n<h2 id=\"step-4-control-website-migration-downtime-with-a-maintenance-window\">Step 4: Control Website Migration Downtime With a Maintenance Window<\/h2>\n<p>Website migration downtime shrinks when you schedule the window around real traffic patterns, not convenience. Check analytics for the quietest hours in your clients&#8217; time zones.<\/p>\n<p>Practical ways to limit downtime:<\/p>\n<ul>\n<li>Run the cutover during the lowest-traffic window you can find<\/li>\n<li>Keep the old server serving until DNS propagates fully<\/li>\n<li>Use a maintenance page for sites that cannot tolerate partial states<\/li>\n<li>Stagger client sites across separate windows if you host many<\/li>\n<\/ul>\n<p>For mission-critical hosting, a short planned window beats an unplanned outage every time. Clients forgive a scheduled hour; they remember a surprise Friday afternoon failure.<\/p>\n<h2 id=\"step-5-run-post-migration-website-checks-before-you-tell-the-client\">Step 5: Run Post-Migration Website Checks Before You Tell the Client<\/h2>\n<p>Post-migration website checks confirm that everything works before you declare success. Telling a client &#8220;we&#8217;re done&#8221; and then finding a broken contact form damages trust fast.<\/p>\n<h3 id=\"run-the-functional-checklist-on-every-site\">Run the functional checklist on every site<\/h3>\n<ul>\n<li>Homepage and key pages load over HTTPS<\/li>\n<li>Contact forms submit and deliver to the right inbox<\/li>\n<li>E-commerce checkout completes a test order and sends the receipt<\/li>\n<li>Database connections and search functions respond<\/li>\n<li>Email sends and receives, including forwarders and aliases<\/li>\n<li>SSL certificates are valid and auto-renewing<\/li>\n<li>Cron jobs and scheduled tasks fire on the new server<\/li>\n<li>Monitoring and backups are active and reporting<\/li>\n<\/ul>\n<p>Run these checks on every site, not a sample. Document results in the migration plan so the scribe&#8217;s log and the verification list match.<\/p>\n<h3 id=\"verify-uptime-independently-not-just-from-the-providers-dashboard\">Verify uptime independently, not just from the provider&#8217;s dashboard<\/h3>\n<p>A provider&#8217;s status page is a starting point, not proof. Set up external monitoring that checks each site from at least two or three locations outside the provider&#8217;s network. That gives you a record you own if availability is ever disputed.<\/p>\n<p>A practical setup:<\/p>\n<ul>\n<li>Ping or HTTP check every 60 seconds from multiple regions<\/li>\n<li>Alert to a shared inbox the whole team can see<\/li>\n<li>Log timestamps, response codes, and durations<\/li>\n<li>Export the log weekly so it survives account changes<\/li>\n<\/ul>\n<p>When you compare your external measurements against the provider&#8217;s SLA records, expect small differences. The provider may measure from inside its network, exclude maintenance windows, or use a different measurement period. Document the discrepancy rather than assuming one side is wrong.<\/p>\n<h3 id=\"know-how-to-claim-an-uptime-credit\">Know how to claim an uptime credit<\/h3>\n<p>If an outage exceeds the guarantee, agreements often require you to file a claim within a set window and to include specific evidence, such as the ticket number, the affected service, the start and end times, and monitoring data.<\/p>\n<p>Keep a simple claim file for each client:<\/p>\n<ul>\n<li>Outage start and end in the provider&#8217;s time zone<\/li>\n<li>Affected service and scope (network, power, hardware, or full service)<\/li>\n<li>Your external monitoring export<\/li>\n<li>The provider&#8217;s own incident reference, if one was issued<\/li>\n<\/ul>\n<p>Service credits are often capped and are typically the only remedy the agreement offers. Read the cap before you promise a client anything.<\/p>\n<h3 id=\"distinguish-the-failure-types-before-you-escalate\">Distinguish the failure types before you escalate<\/h3>\n<p>Not every outage is the provider&#8217;s responsibility. Hardware, network, and power failures usually fall under the agreement. Software, application, and configuration failures usually fall on your team. Knowing which is which tells you whether to open a provider ticket or start your own rollback.<\/p>\n<div style=\"margin:1.5rem 0;padding:16px 20px;background-color:#fffbeb;border-left:4px solid #fde68a;border-radius:0 8px 8px 0\">\n<strong style=\"display:block;margin-bottom:4px;color:#111827;font-size:14px\"> Watch Out<\/strong><br \/>\n<span style=\"color:#374151;font-size:15px;line-height:1.6\">Do not close the migration until the external monitoring has run clean for at least one full business day. A site that passes a five-minute check can still fail under real traffic.<\/span>\n<\/div>\n<h2 id=\"common-mistakes-agencies-make-during-a-dedicated-server-migration\">Common Mistakes Agencies Make During a Dedicated Server Migration<\/h2>\n<p>The most damaging mistakes are process failures, not technical ones. Here are the patterns we see most.<\/p>\n<ul>\n<li>Starting cutover without a written rollback trigger<\/li>\n<li>Forgetting a client&#8217;s mail or a secondary domain during inventory<\/li>\n<li>Leaving DNS TTLs high, which stretches propagation and downtime<\/li>\n<li>Decommissioning the old server before verification finishes<\/li>\n<li>Skipping the hardening pass on the new machine<\/li>\n<li>Failing to retarget hardcoded IP addresses in apps and integrations<\/li>\n<\/ul>\n<p>Each of these turns a routine move into an emergency. A reusable server migration plan template catches most of them before they happen.<\/p>\n<section style=\"margin:3rem 0 2rem 0\">\n<h2 style=\"font-size:1.5rem;font-weight:700;margin:0 0 4px 0\" id=\"frequently-asked-questions\">Frequently Asked Questions<\/h2>\n<div style=\"padding:20px 0;border-bottom:1px solid #e5e7eb\">\n<h3 style=\"font-size:1.1rem;font-weight:600;margin:0 0 8px 0\">How long does a dedicated server migration take for an agency?<\/h3>\n<div style=\"line-height:1.7;font-size:0.95rem\">\n<p style=\"margin:0\">Plan for two to six weeks per server, not a single weekend. Provisioning and hardening usually take a few days, data replication runs for several days on large sites, and the DNS cutover itself takes 24 to 48 hours to propagate. Agencies managing multiple client sites should stagger migrations so one failure does not take down every account at once.<\/p>\n<\/div>\n<\/div>\n<div style=\"padding:20px 0;border-bottom:1px solid #e5e7eb\">\n<h3 style=\"font-size:1.1rem;font-weight:600;margin:0 0 8px 0\">How do you minimize website migration downtime during the cutover?<\/h3>\n<div style=\"line-height:1.7;font-size:0.95rem\">\n<p style=\"margin:0\">Lower the DNS TTL to 300 seconds at least 48 hours before the cutover, put the site into maintenance mode, run a final database sync, then switch the A record. Keep the old server online and serving until the new one has passed every post-migration check. Most agencies see only a few minutes of downtime when they follow this sequence.<\/p>\n<\/div>\n<\/div>\n<div style=\"padding:20px 0;border-bottom:1px solid #e5e7eb\">\n<h3 style=\"font-size:1.1rem;font-weight:600;margin:0 0 8px 0\">What should an agency check before migrating client websites?<\/h3>\n<div style=\"line-height:1.7;font-size:0.95rem\">\n<p style=\"margin:0\">Audit every dependency first: DNS records, MX and SPF entries, SSL certificates, cron jobs, third-party API keys, and any hardcoded IP addresses in the code. Confirm the new server can handle peak traffic and that the client knows the maintenance window. Skipping this step is the most common cause of post-migration email and checkout failures.<\/p>\n<\/div>\n<\/div>\n<div style=\"padding:20px 0;border-bottom:1px solid #e5e7eb\">\n<h3 style=\"font-size:1.1rem;font-weight:600;margin:0 0 8px 0\">How do you roll back a server migration if something goes wrong?<\/h3>\n<div style=\"line-height:1.7;font-size:0.95rem\">\n<p style=\"margin:0\">Keep the old server running and untouched for at least seven days after cutover. If the new server fails, restore the original DNS records, which is why you keep TTL low, and confirm propagation. Document the rollback trigger in your migration plan, such as a checkout error rate above 1 percent, so the decision does not require a meeting at 2 a.m.<\/p>\n<\/div>\n<\/div>\n<\/section>\n<hr>\n<p>Migrating client infrastructure without a tested plan is how agencies lose accounts. ServerPronto supports agencies with dedicated servers provisioned in about two hours, full root access, month-to-month billing with no contracts, and 24\/7 on-site technicians backing a 100% uptime guarantee. Build your migration around infrastructure you can trust. Get started with ServerPronto and move your clients with confidence.<\/p>\n<div class=\"cta-button-container\" style=\"text-align: center;margin: 32px 0\">\n<p>    <a href=\"https:\/\/www.serverpronto.com\/\" class=\"cta-button\" style=\"display: inline-block;background-color: #2563eb;color: #ffffff;padding: 14px 32px;border-radius: 8px;text-decoration: none;font-weight: 600;font-size: 16px\">Build &amp; Price<\/a>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>A step-by-step dedicated server migration checklist for agencies, covering server migration plans, DNS cutover, downtime limits, and post-migration checks.<\/p>\n","protected":false},"author":0,"featured_media":9889,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[409],"tags":[522,524,526,521,523,525],"class_list":["post-9886","post","type-post","status-publish","format-standard","has-post-thumbnail","category-blog","tag-dedicated-server-migration-checklist-for-agencies","tag-dns-cutover-checklist","tag-post-migration-website-checks","tag-server-migration","tag-server-migration-plan-template","tag-website-migration-downtime"],"_links":{"self":[{"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/posts\/9886","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/comments?post=9886"}],"version-history":[{"count":1,"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/posts\/9886\/revisions"}],"predecessor-version":[{"id":9888,"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/posts\/9886\/revisions\/9888"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/media\/9889"}],"wp:attachment":[{"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/media?parent=9886"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/categories?post=9886"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.serverpronto.com\/spu\/wp-json\/wp\/v2\/tags?post=9886"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}