Key Steps in a Server Migration

Key Steps in a Server Migration.
The online blog, Locomotive Agency Server Migration Guide has provided a really useful 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 makes preplanning and the review of a competent SEO important steps critical to the success of a transition.

The following lists 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.

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.

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.

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.

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.

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.

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 the 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.