Pat Wright details how to plan cloud migration with minimal downtime. Learn key cutover strategies, testing methods, and critical questions to avoid data loss and system failure.

Whenever I start a migration, one of the primary questions is: “how much downtime will be supported during the migration?” The answer is always none. That doesn’t usually work in most systems. Typically, the applications you are trying to move to the cloud are not necessarily modern systems, and they are not ready to handle distributed processing.

The goal in this step should be to begin discussing what it will take to move the system. Research the various methods you can use to move the data and the application. Methods such as blue/green deployments, A/B testing, and other ways to move the traffic between your on-premises system and the cloud.

Testing is your best way to start deciding what will and won’t work. This will also give you time estimates for what it takes to actually move the data, and the amount of downtime expected. Listed below are the key questions I always ask during this process.

The key questions you should always ask before moving data

Firstly, task an individual with testing various scenarios and simply moving the data around. How long does it take to move the data from point A to point B?

I then advise gathering the leaders/owners responsible for querying the applications’ databases. Start asking the questions listed below to find out what it means to the application when the data is moved. This is a TEAM effort – not just a DB effort. 

The exact questions to ask the team – and why they’re important

“What data is static (so can be moved just once), or is change infrequent enough to not require this?”

“If we switch over to the new location, what does rolling back look like? Can it be rolled back?”  This is critical to determine if this is a one-way process. This is the most common scenario, and extensive testing is needed.

“Can we take downtime and shut off everything for a clean cutover of the data?”
This is the simplest, cleanest option. You sacrifice speed with this option, but it ensures no data is written to other locations, and that you don’t have any bad data. 

“Are we losing any functionality in this database migration?” It may be that not every feature you had on-prem is available in the cloud. Make sure to know if something is functionally changing about the system.

“Who validates that the cutover is complete?” This is typically handled by quality assurance (QA) and testing teams, but it’s important to have a list of items to test and provide a ‘done’ stamp.

The downtime and cutover discussion is another way to involve everyone who works on the applications. It’s important to understand the applications and how they are used to make this project successful. I hope this advice helps with that process.