Server Migration Checklist

Getting a Server Migration Right

This overview is a non-exhaustive guide to common best practices from an SEO perspective for transitioning a website to a new host.  Obviously there are many factors at play, from host technologies to registrar nuance, which make preplanning and the review of a competent SEO at important steps critical to the success of a transition. We have broken down the key steps in a transition and have provided a checklist to review at launch phases.  This document focuses on technology transitions and not situations where the website’s domain is changing.

Steps in a Server Migration

1. Prep new host: In any website server transition, it is important to have a sandbox environment (normally called staging) on the new host to test your website prior to making live for users.  For many hosts, including WPEngine, this is a very easy process.
2. Copy website to Staging environment: In most cases, sites are built with a database to hold data, and files which tell the server how to display the data and render the page for the browser. There are many options for copying including command-line tools as well as CMS plugins.  This should be left to the developer to pick the optimal route.  During this time, it is recommended to ensure that all files accessible on your current website, including robots.txt, XML sitemaps, PDF folders, etc., are carried over.
3. Q/A staging environment and test active URLs and redirects: After the website has been successfully migrated to your staging environment, you will want to have a team member manually Q/A important pages and functionality of your website.  This is also the time to test all important URLs and historical redirects to ensure that they are working correctly on the staging website.  Your SEO team can crawl the staging site at this time to note any critical SEO changes or missing files.
4. Copy website from staging to production: Once staging has been fully vetted and ready to go, it is time to “push” the staging site to the production site.  On most modern hosts this is either a command-line directive or a button push in their admin section. This is a good time to ensure that production is set up for automatic backups if your host allows it.  It is also a good time to update your version control systems with the current version.
5. Update DNS to live domain, Q/A, and test active URLs and redirects: This is the step for actually making your website live.  It involves updating your DNS name records to the new IP address and thoroughly testing important pages and historical redirections.  You should have your development team members ready for a few hours after launch to handle any important unexpected changes. It is also a good idea to have your SEO team available to crawl important pages, validate important files, and test historical redirects.

Server Migration Checklists:

Prep

• Ensure you have a set of important URLs to use for testing.  This should include URLs that drive organic traffic, any social and ad URLs, as well as important business pages like privacy policy, cart, my account, etc.
• Add current website in ContentKing.  This will alert you to any breaking SEO changes on migration day.
• Ensure that you have a list of all historical redirect rules from the previous server.  Often these are found in the CMS, the .htaccess file, or web server config files. These should be copied over to the new server.
• If any asset (image, JavaScript, fonts, CSS, etc) URLs change during the transition, you will need a cache-busting strategy to ensure that new browser requests for pages aren’t referencing old 404 URLs. Cache-busting is normally handled by appending a unique ID as a parameter to the end of assets.  (e.g. https://www.domain.com/assets/app.js?v=123456)
• Note: If you think that there is a chance that you may have to revert quickly to your old webserver, you can set your asset cache-control directives to not have the browser cache the new URLs.  This should be updated later to efficient policies but can be helpful during migration.
• If any URLs are changing during the transition, ensure that there is a mapping of all old URLs to new URLs.  This is normally a spreadsheet.  The mappings should be used to add 301 redirect rules to your new server.  Often, this looks like Redirect 301 /old-page-path /new-page-path in .htaccess.  This spreadsheet can also be used to validate the URLs are correctly mapped on the new server.
• If you are currently using a CDN, review the host’s or CDN’s documentation to ensure you have a plan in place for deactivating/reactivating after the transfer, as well as purging cached data.
• If you have crawl-log monitoring, prepare a plan to ensure that this data will be available on the new server.
• Plan any social / ad campaign URL changes that will be needed on the new website.
• Pull historical speed, analytics, crawl, and conversion metrics to use as a comparative benchmark for after relaunch.

Staging / Sandbox Environment

• Most current hosts offer a staging environment that is used to test the website prior to pushing live (production).  This is normally set as a DNS A Record pointing to stage.domain.com or www.stage.domain.com.  Some CMS’s and hosts require updating the domain in their settings to qualify the traffic coming to the IP address with the correct staging domain.
• Ensure any SEO plugin in the staging site is reviewed by your SEO team.
• Q/A the staging environment in mobile and desktop browsers and ensure that all important pages are working correctly.
• Test sample important pages in Chrome Lighthouse to resolve any speed, SEO, or usability issues.
• Ensure that you have any request header rules from the previous server.  These can include security rules and browser caching rules. (see note in prep section)
• Test important URLs and redirects against the URLs on the staging server.  If important URLs are 404, they should either be added to the staging environment or redirect rules should be updated to 301 redirect to the closest relevant page.
• Ensure all URLs have a self-referencing canonical link element. 
• Ensure a custom 404 page is in place.
• Check for console log errors in Google Chrome Developer tools.
• Ensure any tracking validation files are carried over to the new server.
• Update your robots.txt to match the previous server.
• Add password protection to the staging site to ensure search engine crawlers can’t access it.
• Make sure to update your Analytics and tag manager codes to the staging environment.  Validate they are active and receiving traffic and that any conversion goals are firing. 
• Ensure that an XML sitemap is available on staging and that it only lists indexable pages that you want to appear in search results.
• If using an external asset CDN, it is worthwhile testing on staging to ensure there are no broken assets being requested.
• Review meta robots and header robots directives across key pages.

Migration

• Plan to do migration during a slow period, like a weekend or late night.
• Keep the old server active for several weeks after the migration.
• Add annotations in Analytics tools.
• Push staging server to production using host-specific workflow.
• Update domain DNS records to point to new IP address.
• Optional: You can create an old.domain.com pointing to your old server’s IP if it is helpful for team members to validate new pages are pixel perfect, or if it can be used to quickly carry over any missed content.
• Ensure the domain is updated in your CMS or Host settings.
• You can use What’s My DNS to check the replication of the new IP address.  You can also flush your computer’s DNS resolver cache (ipconfig /flushdns ) or edit your hosts file to force your ability to see the new server.
• Validate that http://domain.com, https://domain.com, http://www.domain.com. https://www.domain.com all resolve 200.
• Validate that your XML sitemaps and robots.txt files are live and accurate. Ensure the XML sitemap is active in Search Console.
• Make sure to update your Analytics and tag manager codes to the new environment.  Validate they are active and receiving traffic directly after migration.
• Validate that any crawl-log monitoring is receiving new traffic.
• Review meta robots and header robots directives across key pages.
• Reactivate CDN, if available.

Post Migration

• If any URLs change during the transition, you will need to update any internal links pointing to the old URL versions.  This can often be done via search and replace of the CMS database but should be done with extreme care to ensure that searched items are explicit enough to ensure non-targeted items are not changed.  It is also important to update any hard-coded changing URLs in your theme files.
• Ask IT to flush any internal network DNS resolve caches to ensure that your company or client is able to receive the new IP address. Sometimes domain IP addresses are cached at a local network level and it can be weeks before they are updated.
• Review traffic to the old server and validate that it is no longer receiving hits.
• Crawl the new site and ensure there are no 404 pages or redirect chains (where a requested page has multiple redirects prior to landing on the 200 version).
• Validate important pages pulled during prep are all resolving ok.
• Test sample important pages in Chrome Lighthouse to resolve any speed, SEO, or usability issues.
• Check for console log errors in Google Chrome Developer tools.
• Fetch and render several key pages in Search Console to ensure no issues.
• Monitor server log files to ensure there are no spikes in 50X or 40X errors.  Ensure the average response time is < 200ms.
• Test structured data in new environment.
• Review Search Console and Analytics 5 days after launch and immediately address any traffic issues.
• Ensure asset files have efficient policies set for caching.

Whether you’re about to undertake a server migration or you just need SEO solutions for your business that will work, reach out to LOCOMOTIVE Agency. We have expertise and experience that will make a difference.