There are a lot of compelling reasons for enterprises to migrate their on-premises datacenter into the public cloud: scale, agility, automation, regional support, cost, etc. All of these are great boosts to IT and the business itself. There is an interesting (potential) caveat with cost that many enterprises can’t often anticipate early on, though, and that’s the double infrastructure paradox.
The double infrastructure paradox is when an enterprise has decided to move to the public cloud to achieve cost benefits but actually ends up spending twice as much on operating cost. This happens when enterprises end up having to run their new cloud environment in addition to their existing on-premises environment (in parallel) for an extended period of time. Hence, “double infrastructure”.
In this case, they’re paying for the public cloud and they’re paying to manage and maintain their existing on-premises environment, too, which sends costs skyrocketing. So, why would any enterprise entertain this paradox? The sad reality is that if an enterprise is doing this it’s because they don’t have any other easy options. So, the better questions become “how does this happen” and “how can enterprises avoid it altogether”?
What typically causes the double infrastructure paradox is simple. An enterprise decides to migrate to the public cloud but ends up facing obstacles along the way while they’ve got one foot in (the on-premises datacenter) and one foot out (and now in the public cloud). The reason this ends up happening is most commonly a result of a lack of any of the following:
- Discovery: the enterprise was not able to do a full discovery of their application landscape, which meant that they didn’t fully grasp the architectures of the applications they were trying to migrate into the public cloud. This led to things getting messy and IT ending up entangled between on-prem and the cloud.
- Validation: thorough, real-world, production-level testing wasn’t able to be performed. As an example, maybe a bare bones version of an application was tested in the cloud that lacked production-grade integrations and/or data. This leads to a false sense of cloud validation, but when the production application actually migrates, performance isn’t strong enough and end users are unhappy.
- Cutover: part of a data set has migrated to the cloud, but with production environments that data set is always changing. It’s difficult to find an extended period of time to turn an application off and then fully migrate it into the public cloud. For mission critical applications especially, this can be a hard ‘last step’ to accomplish.
- Rollback: when things go wrong it’s sometimes easiest to just roll everything back to on-premises, but this isn’t always an option depending on what cloud migration solution you’ve picked. That means that if an application doesn’t work quite right after weeks (or months) of transferring things into the cloud, there is still no easy way to revert back to on-prem without losing recent data.
- Stagnation: in some cases, there isn’t any one thing (like the above four cases) that went wrong, but the cloud migration solution is just taking forever. Maybe it’s not WAN-optimized, maybe it’s just a poor protocol, or maybe it wasn’t designed for cloud migration. Either way, things are dragging on for months which means on-prem and the cloud are both turned on and costing money.
All of these scenarios can result in the double infrastructure paradox, where you have some subset of your on-premises landscape running in (or at least transferred into) the public cloud, but in such a way that you still can’t decommission your on-premises infrastructure. Now you’re paying for both and with no easy way out.
So, how can enterprises avoid finding themselves in this situation? The answer is that during any pilot of a cloud migration solution, the right questions have to be asked, and the right tests have to be performed. For an enterprise-grade mass migration, it isn’t enough to pilot a solution with small, bare-bone applications and tiny data sets. That’s not enough to make sure that the solution can truly accomplish what you need.
Which means when you embark on a pilot to test out a cloud migration solution, make sure you validate it can do all of the following with a multi-tier, complex, stateful, large application:
- Integration with a planning and discovery vendor, so as to truly map out the application landscape.
- Testing of actual applications with actual data directly in the cloud but in a way that does not impact the live environment (or disrupt users or data).
- Seamless cutovers, where data deltas are managed and maintained automatically, and maintenance windows are easy to schedule in advance and last for only a short period of time.
- Fast rollback to on-prem without any data loss or extended downtime, just in case something doesn’t go as planned.
- Last but not least, a solution that is fast. Make sure your cloud migration solution is WAN-optimized, and that it can handle migrations over small uplinks, perform automation and scaling, and in general just keep the pace of your cloud migration going fast. The faster you’re seamlessly in the cloud, the sooner your on-prem infrastructure is decommissioned.
Although there are many more capabilities an enterprise should look for in their migration solution, these five will help eliminate the possibility of the double infrastructure paradox. Simply put, your cloud migration solution should be able to demonstrate enterprise-grade readiness during the pilot. If they can’t, it’s best to move on, lets you want to find yourself in muddy waters halfway through.
And, what about enterprises who are already in the paradox and trying to get out? This will be a bit more challenging, but it’s never too late to switch cloud migration solutions. In fact, some of Velostrata’s greatest success stories are where we replaced an existing vendor mid-migration, like we did at the Department for Education in the UK, as an example. The honest truth is that sometimes its faster, easier, and cheaper to start over with the right cloud migration solution, instead of trying to trek your way through with the wrong solution.