Server and Domain Migration Checklist for Mission Critical Operations
This document will be used as a checklist for server migrations.
Important Notes (Check to Confirm the Completion of Each Step):
[ ] Make a copy of this document and do NOT edit the original.
[ ] I understand that this is a generic checklist. Where changes apply, I will change my copy so that it makes sense for my use case.
STEP ONE:
List all assets tied to the domain here:
STEP ONE A:
[ ] Asset storage (i.e., S3 Buckets, Image & Video Folders etc.)
STEP ONE B:
[ ] Databases (i.e., MySQL Lightsail instances, Amazon RDS etc.)
STEP ONE C:
[ ] Instances (i.e., Runners, Lightsail cPanels etc.)
STEP ONE D
[ ] Content Delivery Networks (i.e., Cloudflare, Imagekit etc.)
STEP TWO:
Backup all assets
STEP TWO A:
[ ] For this step, check to verify that a back up has been performed for each asset in Step One A.
S3 Buckets — Backup Confirmation
STEP TWO B:
[ ] For this step, check to verify that a back up has been performed for each asset in Step One B.
Databases — Backup Confirmation
STEP THREE C:
[ ] For this step, check to verify that a back up has been performed for each asset in Step One C.
Instances — Backup Confirmation
STEP THREE:
[ ] Read documentation as it pertains to the switch, and record any important / resources points here:
[ ] Important Note: If you’re switching a domain that has emails attached to it, ensure those emails will transfer over to the new domain and not disrupt business operations.
STEP FOUR:
[ ] Setup new server
STEP FIVE:
[ ] Setup database server
STEP SIX:
[ ] Setup redis / caching server (inside the new server). Note that this step is Laravel specific and may not apply to your use case.
STEP SEVEN:
[ ] Setup load balancer
STEP EIGHT:
[ ] Setup connection from server to database
STEP NINE:
[ ] Setup CI/CD
STEP TEN:
[ ] Setup npm commands to auto generate css and js every deploy
STEP ELEVEN:
[ ] Setup supervisord on the new server (to auto start background process every time it crashes or we have a server restart). Note that this step is Laravel specific and may not apply for your use case.
STEP TWELVE:
[ ] Setup any other sub-sites that might be used. For instance, a Laravel site that uses WordPress for a blog in a sub-directory. At this step, we had to setup the wordpress /blog on the new server and copy all files from live /blog
STEP THIRTEEN:
[ ] If applicable, start working on the inventory sync using the inventory API. This step may not apply.
STEP FOURTEEN:
[ ] Copy DNS config from CDN (e.g., Cloudflare) and apply to new host (e.g., AWS Route53) if applicable
[ ] Lower DNS TTL (Time to Live) to 5 minutes at least 2 days before the name server migration.
[ ] Setup new host to point to the application load balancer (if applicable).
[ ] Update App Config with new values.
[ ] Whitelist the new server IP on email provider (e.g., SendGrid, Mailchimp etc) Otherwise, emails won’t send after the switch.
[ ] Copy Cron jobs onto the new server.
[ ] Ask managers to review your work thus far.
STEP FIFTEEN:
[ ] List the new name servers here:
STEP SIXTEEN:
[ ] Get with managers and have them notify all staff by sending out an “All Staff” email, as well as an @ here notification in Slack. In this notification, let everyone know the time at which you expect to perform the name server switch (i.e., server migration).
STEP SEVENTEEN:
[ ] Contact managers so that they can review your work and set the nameservers on the original host (e.g., GoDaddy) to be changed to the new host (e.g., Route 53) nameservers.
STEP EIGHTTEEN:
[ ] Migrate all associated databases. To use an example, we had to migrate:
The Main site
The Admin site (i.e., backend management panel)
The Customer Resource Management Panel (i.e., CRM site)
The dev site
The staging site
The dev Admin site
The staging Admin site
The dev CRM
The staging CRM
(Note: If you have a three stage development process, this makes for a total of 9 different sites to check and remain mindful of!!)
STEP NINETEEN:
[ ] Setup SSL for HTTPS
STEP TWENTY:
[ ] After DNS propogation (10 minutes to 48 hours), perform testing of all features and all site functionality.
[ ] Testing features to stay especially mindful of include:
[ ] Form Integrations (often the source of customer interaction)
[ ] Company emails (both send and receive)
[ ] Analytics and tracking tags (are they still working?)
[ ] Payment portals (are they still working?)
[ ] Old links with rich SEO (are they the same as the old site, or do they at least redirect to the new site?)
[ ] Add anything else you might need to test here:
