# A Pre-Deployment Checklist for Risky Data Migrations

DevFeed: [A Pre-Deployment Checklist for Risky Data Migrations](<https://devfeed.tech/articles/the-checklist-for-deploying-a-scary-change-19165.md>)

Original publisher: [Read original article](<https://artsy.github.io/blog/2023/09/13/deploying-a-scary-change/>)

Published: 2023-09-13T00:00:00Z

Content type: tutorial

Language: en

Sources: [Artsy](<https://devfeed.tech/sources/artsy.md>)

Topics: [Command-line interface](<https://devfeed.tech/topics/cli.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Kubernetes](<https://devfeed.tech/topics/kubernetes.md>), [Sidekiq](<https://devfeed.tech/topics/sidekiq.md>), [Latency](<https://devfeed.tech/topics/latency.md>)

Tags: [command-line](<https://devfeed.tech/tags/command-line.md>), [data-migrations](<https://devfeed.tech/tags/data-migrations.md>), [deploy-process](<https://devfeed.tech/tags/deploy-process.md>), [docker](<https://devfeed.tech/tags/docker.md>), [error-reporting](<https://devfeed.tech/tags/error-reporting.md>), [kubernetes](<https://devfeed.tech/tags/kubernetes.md>), [latency](<https://devfeed.tech/tags/latency.md>), [logs](<https://devfeed.tech/tags/logs.md>), [migrations](<https://devfeed.tech/tags/migrations.md>), [retry](<https://devfeed.tech/tags/retry.md>), [ruby-on-rails](<https://devfeed.tech/tags/ruby-on-rails.md>), [sidekiq](<https://devfeed.tech/tags/sidekiq.md>)

## AI overview

This article presents a pre-deployment checklist for risky data migrations and other changes that could affect production services. It recommends planning rollback steps and monitoring error rates, reported errors, latency, logs, functionality, and failing Sidekiq retries after deployment.

## Source excerpt

Lately, I've been getting involved with some sketchy stuff. You know what I'm talking about-data migrations. I've been rolling out changes that have a significant risk of breaking our production environment for mission-critical services. It's been exciting work (keep your eyes out for more posts on the exact project, coming soon™), but I've definitely caused a couple incidents along the way. After accidentally taking down a key service for a couple hours, I decided I needed to have a better pre-deploy process for these changes. I did some thinking and came up with a short checklist to run through before I press the shiny green button. Here's the checklist I came up with: What is your plan if something goes wrong? Run through ramifications of rolling back. If there's a reason you're worried about rolling back, then you're not ready to deploy the change yet! Figure out exactly what command(s) you will need to run to roll back. At Artsy, this is usually a one-liner using Hokusai, our command-line Docker/Kubernetes CLI How will you tell if something is going wrong after you deploy? Error rate (DataDog) Specific error reporting (Sentry) Latency (DataDog) Logs (Papertrail) Functionality (does it still work? Are people using it successfully? Important for things where errors may not be bubbled up correctly or reported immediately) Sidekiq (are there lots of jobs queued to retry that are failing?) With this checklist in hand, I'm deploying more confidently and causing fewer incidents along the way. Do you have something similar? Are there things you think this checklist should include? Let me know in the comments!