6 Constraints for Every Cloud Migration: A Checklist

It's safe to say that every organization would like to optimize their data by moving it to the cloud. Unfortunately, doing so is far easier said than done. The average company has at least several hundred terabytes of data. It is no small feat to transfer this amount of data, both structured and unstructured, to the cloud.

However, there are ways of making the transition easier. One of those ways is to recognize the possible constraints that may be encountered while performing the transfer. When conducting a cloud migration, there are six constraints to consider: bandwidth, working hour restrictions, downtime impact, peak timeframes, legal restrictions, and timezone constraints.

Throughout this post, we will walk through each of these constraints and how to mitigate any associated risks. Let's start by discussing how bandwidth can have an adverse effect on your cloud migration.

Constraint #1: Bandwidth

One of the most important things to determine when migrating to the cloud is how long the actual migration will take. When making this determination, bandwidth is important to consider. Bandwidth refers to how quickly the data is uploaded into the cloud. For example, let's say you have a database that contains 100 TB of data.

On average, a typical migration allows for transfers of 1 gigabyte per second. Realistically this does not pan out, and the average for this type of network is more in the ballpark of 1 GB per 8 seconds. That means that a 100 TB table could take about 12 days to fully transfer over. This is not even accounting for connection resets or any other issue that may arise.

Not only does bandwidth matter during the transfer itself, but it is of vital importance once the data is finally migrated. Now your on-premise applications will have to communicate with a cloud server that could be thousands of miles away, while before they only had to communicate with a database a thousand feet away. This may cause a considerable latency issue. Make sure to do a test run and verify your customers will have the proper experience before making the full leap.

With all that being said, make sure your organization fully understands how long it will take to transfer all of that data into the cloud.

Constraint #2: Working-Hour Restrictions

Cloud technology is still relatively new, which means finding trained employees can be quite difficult. That means the cloud migration can and should only occur when the dedicated employees are on the clock. For instance, if the lead architect is on PTO, then it may not be the best time to perform the migration. Oftentimes misconfigurations can stymie a cloud migration — so it is worth it to wait a day or two instead of involving a less experienced team member.

In order to mitigate these sorts of risks, make sure that a designated schedule is in place. Additionally, because cloud migrations generally take days, ensure that an on-call rotation is implemented. That way the appropriate cloud migration specialist can be called in case anything hits the fan. Having the right people for the right job will have a direct effect on the possibility of downtime: so let's talk about that next.

Constraint #3: Down-Time Impact

Whenever a cloud migration occurs, there is a distinct possibility that critical applications will be unavailable to your consumer. Make sure that a plan is set up to ensure downtime is at a bear minimum for critical applications.

For instance, create a replica of your data in the cloud first. Now the data will be in two places: the on premise datacenter and the target cloud. Once the application itself is migrated, test its link to the database in a non-production environment. Next make sure that everything is good to go, then switch the data source to the cloud in production.

Remember, it is okay to have downtime as long as the organization can afford it. It may be far easier to simply take the system offline, perform the migration, and bring the app back online in the cloud. It is all about doing the proper analysis prior to the migration. If downtime will cost a couple hundred dollars of revenue, then it is probably fine…but a couple hundred thousand? That would be a problem. Next, let's look at peak timeframes and how it could be an obstacle to the cloud migration.

Constraint #4: Peak Timeframes

The data migration ought to occur when as few employees as possible are on the network. For instance, midnight on Saturday would be a good time to perform the migration. The amount of strain on the network would be minimal because (hopefully) no one will be working. Another good reason to do this is to make sure that in the event anything does go wrong, then the bare minimum amount of users will be affected. Coordinate with management to ensure that the migration is happening at the best possible time.

However, earlier we mentioned that bandwidth constraints could cause a data transfer to take days. This can be mitigated by halting the data migration during mission critical hours. However the team decides to pull off the migration, ensure peak time frames are included during any risk evaluation meetings.

Constraint #5: Legal Restrictions

In my experience of performing cloud migrations, this is the constraint that has popped up the most. Legal restrictions refer to the fact that some data cannot be transferred to the cloud due to a certain contractual example. Let's take a look at a real-life example of when this was an issue.

Let's say you work at an insurance company, and your mission is to transfer your client's data to the cloud. However one of those clients is in direct competition with the cloud provider. In this particular instance, Walmart would not allow their data on AWS, because Amazon is a competitor. For the insurance company, this was an unforeseen constraint. The migration was halted and a new plan had to be developed for that particular client.

Another more common example is the storage of personally protected information (PPI). Oftentimes a company has contractual obligation to store their PPI in a pre-approved location. In order to migrate the data, that contract will need to be altered. In conclusion, make sure that all legal ramifications have been thoroughly investigated before migrating your data.

Constraint #6: Time Zones

Any programmer will tell you that working with timezones is notoriously difficult. For instance, when fetching a time from a database, there may be the need to convert it to the current timezone or vice versa. One of the best ways to avoid timezone constraints is by ensuring that all timestamps are converted to Universal Coordinated Time. (UTC)

UTC is a standardized time zone that is the same in every region of the world. It is based on the mean solar time at 0° longitude. It is the standard used by all three of the major cloud players: AWS, Azure, and Google Cloud. So before making the migration, ensure all timestamps are in UTC format. Make sure that all applications are thoroughly tested and working correctly once this format is implemented.

Final Thoughts

Cloud migrations are notoriously difficult and time consuming processes. However it is indisputable that the payoffs for both your employees and customers are huge. Disaster recovery becomes far less stressful and downtime is greatly reduced once your apps and data are in the cloud.

By following this checklist, not only will you have knowledge to pass cloud certification exams such as the CompTIA Cloud+, but you will also have the confidence to perform a seamless cloud migration.