Considerations in data migration between cloud providers

Last week I met a friend who is the operations manager for a medium Intenet company. He told me about his planned migration from one cloud provider to another: "Bill for bill - we will save at least 15% on our monthly cloud expenditure."

"What about the migration project?" I asked. His reply caught me off guards: "At 15% bill discount - it does not matter".

This is actually a common practice in many of the companies using a single cloud provider: take the public cloud monthly bill and ask the competitor for a discount rate in case you migrate over. Unfortunately, this "bill for bill" comparison disregards the migration project, and one may find that the "lift and shift" project will both eat most of the planned savings, as well as consume more time, efforts and resources compared to the initial hunch.

So – does your planned project of data migration between cloud providers makes sense?

The secret to delivering high-value projects is trimming off least profiting projects , and preferably kill them before they even start. A negative ROI is a clear indication of a project you should not chase or should be killed early. If the ROI is positive, you can consider it but then use either NPV and/or WACC to help with project prioritization as they factor time - not the one with the highest ROI.

In the below, I’m suggesting a method to help you quickly identify cloud migration projects that will have negative ROIs.
I’m well aware that this is just one component of the overall migration project from one cloud provider to another, and as that is the case, feel free to plug it in your decision matrix, use it as supporting/leading indicator or simply post a nasty comment below.

Where can you focus your attention, and where should you actually focus it?

I’m not going to choose sides on the Agile vs Waterfall war. I’m assuming the costs would be similar either way. There are 3 types of costs in any such project:

Planning costs are all costs that are associated with analyzing the steps that need to be done in the project, what needs to be done in each step, estimating the length of each stage in the project, it’s complexity, risk, resources etc.
These costs are the hardest to evaluate, and would have the greatest implication on the project.

Execution costs are all costs that are associated with executing the planned steps. Easiest and very naïve way to think about those is the price you’ll pay a 3rd party to execute your well prepared project planning document. Main challenge in evaluating this cost is the inherent gaps between planning and wanted reality on one side, and the inherent gap between developers and the rest of the world on the other.

Utility costs are all the costs that are easy to identify, evaluate and should yield the least variance between planning and reality. Think energy costs, network cost and water cost.

If the utility costs savings don’t make sense, you can safely kill the project

Disregarding meta-data activities, specific features or personal preference a specific cloud brand, you should remember that there is a high cost in reading data out of the public cloud providers. This cost is usually stated on their pricing pages as "Egress cost", "Bandwidth costs" and "Data Transfer OUT From Amazon S3 To Internet" etc. If your storage's cost saving would not cover the egress cost, the ROI will be negative. As the egress costs are attributed to a one-time activity - people tend to either totally disregard it or look at it as a project killer and both approaches are naive. A better approach is to assume this cost will be overloaded for a time period and then we can look at the overall saving. The number of months to overload can be debated forever, but I personally tend to use 12 months for such an evaluation since the primary motivation for using the public cloud is elasticity and flexibility, and thus I want to be able to change things fast if something new comes up as opposed to assuming "we can't make a change because we look at 5 years ROI cycle and just went through a refresh".

I’ll use the following:

Source cloud storage costs (SCS)
Source cloud egress/outbound to internet costs (SCE)
Target cloud storage (TCS)
Egress overload months (OLM)
Kill this project indicator (pKPI) = (SCS-TCS)xOLM - SCE
Kill the project if pKPI < 0

Here is a helpful sheet I created for this

Let’s use some real-life example:
Let's say you have some data on AWS S3 (the source cloud) and you want to move it into Azure Blob storage (the target cloud). Looking at the prices from the public website (Aug 2017):

(SCS) = $0.023 per GB/Month (ignoring the discount due to amounts)
(SCE) = $0.085 per GB
(TCS): $0.017664 per GB/Month
(OLM): 12 month (my choice).
pKPI = ($0.023 GB/Month - $0.017664 GB/Month)x12 Months -$0.085 GB ) = -$0.021

So you can kill safely the project. If you feel you want to do the project you can negotiate the storage prices further down, ask for the target cloud to pickup the egress and/or total "lift and shift" costs or look for a multi-cloud solution that would remove all egress costs from the equation.

WOO HOO! Positive pKPI!!!

Nothing to be jolly about as we failed to kill the project the easy way.
It's time to get our hands dirty and move on to part 2 where I discuss the planning costs that can highlight negative ROI.

NooBaa Blog