“
n
n
Everything you need to know about moving your website to a new host. Safely, step by step, without tanking your rankings or losing traffic.
nnn
n
n
n
n
n
n
n
n
n
nnn
“We moved 47 client sites to Papa Bear over the last year. Not a single one lost rankings. The difference is having someone who actually knows what they’re doing handle the DNS, redirects, and server config before flipping the switch.”
n
n
nnn
n
Moving your website to a new hosting provider sounds simple enough. Export some files, copy a database, point your domain to the new server. Done, right?
n
Not even close. If any part of the migration chain breaks (DNS propagation, SSL certificates, redirect mapping, file permissions, database collation), your site either goes dark or starts serving errors. And when Googlebot crawls a broken site, your rankings drop. Sometimes permanently.
n
But here’s the deal: website migration can be totally safe if you follow the right process. Thousands of businesses move hosts every month without losing a single ranking position. The difference is preparation and execution.
n
This guide walks you through exactly what you need to do (from pre-migration audits to post-move recovery), so your site comes out the other side faster, more secure, and ranking just as well (if not better).
n
Think of it like moving houses. You don’t just show up at the new place with everything in trash bags and hope it works out. You pack carefully. You label boxes. You plan the route. You test the locks before you move in. Website migration is the same exact thing. Skip the prep and you’re asking for trouble. Do it right and nobody even notices you moved.
n
nnn
n
Before you touch a single file, you need a full picture of your current setup. Skipping this step is the number one reason migrations go wrong.
n n
n
n
n
n
n
n
n
n
n
n
n
n
nn
Run a full site crawl using tools like Screaming Frog or Sitebulb. This gives you a full URL inventory: every page, redirect, image, CSS file, and script. Save the crawl report. You’ll use it to verify everything moved correctly later.
n
nnn
n
Never migrate directly from old server to new server while both are live. That’s asking for data corruption, race conditions, and downtime.
n
Instead, get your new hosting environment ready before you move anything:
n n
n
n
Your new server needs the same PHP version, MySQL version, and module configuration as your old one. At least initially. You can upgrade after the migration is verified.
n
n
n
n
Set up a temporary domain or subdomain pointing to your new server. Deploy the migrated site there first. Test everything before you commit to the DNS change.
n
n
n
n
Run speed tests and uptime checks on the new server before you move any files. Make sure the infrastructure itself is solid.
n
n
n
nnn
n
This is where the actual migration happens. You’ll transfer three things: your website files, your database, and your server configuration.
nn
n
Use rsync or a secure FTP client. Avoid web-based file managers for large sites. They time out, corrupt archives, and miss hidden files. If your site is over 2GB (common for WooCommerce stores or media-heavy sites), rsync is your best bet. It can resume interrupted transfers and only copies files that changed.
n
nn
n
Export your database using mysqldump or your CMS’s built-in exporter. For WordPress sites, use a plugin like WP Migrate DB or All-in-One WP Migration. They handle serialized data correctly (a common source of broken sites).
n
Critical: If you’re changing the site URL (domain name or path), you need to update all occurrences of the old URL in the database. This is where serialized data in WordPress and other CMS platforms gets tricky. You can’t just do a simple find-and-replace. Use dedicated tools for this.
nn
n
Install your SSL certificate on the new server before you switch DNS. If you use Let’s Encrypt, you can generate a new certificate during the staging phase. Most managed hosts (including Papa Bear) handle this automatically for you.
n
nnn
n
DNS propagation is where most migrations fall apart. Googlebot doesn’t wait for your DNS to settle. It crawls when it crawls. If it hits your old server first (or a half-propagated state), it might index stale content, 404s, or errors.
n n
Pro tip: Reduce your DNS TTL (Time To Live) to 300 seconds (5 minutes) at least 48 hours before the migration. This way, when you finally point your DNS to the new server, the change propagates globally in minutes instead of hours or days.
n
nn
n n
| Timeline | Action | Why It Matters |
|---|---|---|
| 48 hours before | Reduce TTL to 300s | Speeds up DNS propagation on migration day |
| 1 hour before | Final backup of old server | Captures any last-minute changes |
| Migration window | Transfer files + database | Keep old site live during transfer |
| After verification | Point DNS A record to new IP | Low-traffic window recommended |
| 24-48 hours after | Restore TTL to normal (3600-86400s) | Reduces DNS query load on your server |
| 1 week after | Decommission old hosting | Keep old server running in case of rollback |
n
n
nnn
n
If any URL on your site changes during the migration, you need a 301 redirect from the old URL to the new one. This includes:
n n
n
n
n
n
n
nn
Compare your pre-migration crawl report with your post-migration crawl. Every URL from the old site should return a 200 (on the new server) or a 301 (to a new equivalent URL). Anything returning 404 is lost link equity.
nn
n
n
n
n
n
n
n
n
n
nnn
n
Once the DNS change propagates, run through this verification sequence. Don’t rush it. Take your time and test methodically. A thorough post-migration test takes about 2-3 hours for a standard site, but it’s time well spent.
n n
n
n
Load the site from multiple locations (using a geo-check tool). Verify all pages, forms, buttons, and navigation work. Check mobile and desktop layouts.
n
n
n
n
Submit your new sitemap to Google Search Console. Run a crawl with zero 404s expected. Check that meta titles, descriptions, and canonical tags are correct. Verify robots.txt is not blocking anything important.
n
n
n
n
Run PageSpeed Insights, GTmetrix, and WebPageTest. Compare scores to your pre-migration benchmarks. The new server should be faster. If it’s not, investigate.
n
n
n
n
Send and receive test emails. Check SPF, DKIM, and DMARC records. Verify email forwarding rules still work.
n
n
n
n
Verify SSL certificate is active on all pages (no mixed content warnings). Check file permissions. Run a security scan. Confirm the firewall is active.
n
n
n
n
Confirm Google Analytics / Matomo tracking codes are still firing. Check Search Console for crawl errors. Set up uptime monitoring on the new server.
n
n
n
nnn
n n
n
Even with low TTL, some ISPs and browsers cache DNS aggressively. You might see the new site while your visitors still hit the old one. Googlebot also operates from different data centers around the world, each with its own DNS cache. Fix: Use a DNS propagation checker and keep the old server running for at least a week.
n
n n
n
You tested the homepage. Looks great. But what about the checkout page? The contact form? The blog archive page 47? Fix: Run a full crawl and manually test critical paths like login, checkout, and form submissions.
n
n n
n
A simple find-and-replace on a WordPress database will corrupt serialized PHP arrays. Your site will load blank pages or throw fatal errors. Fix: Use WP-CLI’s search-replace with the –all-tables flag, or a proper migration tool like WP Migrate DB.
n
n n
n
DNS propagation is unpredictable. If something goes wrong at noon on a Monday, you’re losing real revenue by the minute. Fix: Schedule migrations for low-traffic windows. Late night or early morning (2-5 AM) in your timezone is ideal.
n
n n
n
A client once canceled their old hosting the same day they migrated. Eight weeks later Google was still serving cached pages from the old server and users couldn’t log in. Fix: Keep the old server running for a minimum of 7-14 days after migration. Some hosting providers bill monthly. That extra month is worth the insurance. Another trick: keep a full backup of the old server on hand for at least 90 days after migration. You never know when you might need to reference an old config file or restore a specific data set.
n
n
nnn
n
Every migration we handle comes with a dedicated engineer who manages the entire process from start to finish. No handoffs. No “level 1” support reading scripts. Just someone who knows servers, who tests everything, and who stays on the call until your site is fully live.
n n
n
n
n
n
n
n
n
n
n
n
n
n
nnn
n
Some ranking fluctuation after a migration is normal. Even when you do everything right. Google needs to recrawl and reindex your site on the new server. This usually resolves within 2-4 weeks.
n
Here’s what to track in the first month:
n n
n
n
n
n
n
nn
If you see an increase in performance and rankings after migration (which happens with most Papa Bear migrations), it means your old host was holding you back. Higher-quality infrastructure, better caching, faster responses. Google rewards that.
n
One thing most guides don’t tell you: sometimes your rankings actually go up after a migration. Not because you did anything special with the redirects, but because your new server responds faster. Google has been open about using page speed as a ranking factor since 2018. If your old host was throttling your performance (shared hosting overselling is a real problem), switching to a better host gives you an automatic SEO bump.
n
nnn
n n
n
Small WordPress sites (under 1GB) can be migrated in 2-4 hours. Larger sites with complex configurations, custom applications, or multiple databases can take 2-3 days of preparation, followed by a 1-2 hour migration window.
n
n n
n
Not if done properly. Email and website hosting are independent services. Your email can stay on the old provider (or move separately) while your website moves. Just make sure the MX records in your DNS are correct after migration.
n
n n
n
If the idea of managing your own server software, security patches, and performance tuning sounds stressful: yes. Managed hosting means the provider handles the technical side so you can focus on your business. Papa Bear migrations are fully managed. We do the work, you approve the launch.
n
n n
n
A proper migration plan always includes a rollback strategy. If the new environment doesn’t work as expected, you can point your DNS back to the old server within minutes. Never decommission your old hosting until you’ve verified the new setup for at least a week.
n
n n
n
Yes. Always create a full backup (files + database) before starting any migration. Store it in at least two locations: one on your local machine and one in cloud storage. Use a backup plugin or manual rsync backup.
n
nn
n
Run performance tests before and after. Use GTmetrix, WebPageTest, and Google PageSpeed Insights. Compare TTFB (Time to First Byte), LCP (Largest Contentful Paint), and total page load time. A good migration should improve all of these. Most Papa Bear clients see 40-60% improvement in page load times after migration.
n
nn
n
You can absolutely do it yourself if you’re comfortable with cPanel, FTP, and databases. But for business sites where every visitor and every ranking matters, having a professional handle it removes the risk. One wrong DNS setting can take you down for hours. Papa Bear offers free migration with any managed hosting plan. That means a pro handles it and you don’t pay extra.
n
nn
n
Independent migration services charge anywhere from $150 to $1,500 depending on the complexity of your site. With Papa Bear, it’s free when you sign up for a managed hosting plan. Basic cPanel-to-cPanel migrations generally cost less, while custom applications or database-heavy sites with specific server requirements cost more.
n
n
nnn
n
n
Let Papa Bear handle your entire migration. Free of charge when you sign up for any managed hosting plan. No downtime. No lost rankings. No stress.
n
Plans from $33/mo
n Claim Your Free Migration 🐻 u2192n
Free migration available on annual plans. 30-day money-back guarantee.
n
nn
n”
