One of the hip terms that you hear a great deal in Silicon Valley is “fail fast.” This means to find out what does not work so you can move on to what does. It’s solid advice, for the most part.
However, failing in some enterprises’ IT shops may get you put out of the organization, so many IT pros avoid failure at any cost—or at least never declare failure, even if it means spending millions of dollars in dealing with ineffective systems that are costly to run or even hurt the business.
For the cloud, you need to know when to declare a “fail,” when to hit the reset button and start from the beginning when doing migrations.
I bet if you look at your cloud migration projects now around the company, at lwast 20 percent are in big trouble. While the reasons for running into trouble that can lead to outright failure vary, these are the big three that I’m seeing:
- Lift-and-shift is not working.
- Data integration is an afterthought.
- Compliance or security issues have not been addressed.
The biggest issue with migration of applications is the false belief that if it runs on premises on platform A (say, on Linux with four cores), provisioning virtual platform A on a public cloud using the same configuration means the application should work there as well. Umm, often no.
The result of such assumptions is that IT organizations run into issues around communications with systems that have not moved to the public cloud yet, or that their cloud bills are 300 percent higher than expected.
The reason: These lifted-and-shifted applications aren’t optimized for the cloud platform, either for functionality or costs. They don’t use native cloud features, so the value of moving to the cloud has gone out the window; indeed, it may cost you much more.
When that happens, there is nothing you can do other than declare failure and go back to the migration drawing board, this time refactoring to use cloud-native systems, as well as optimize it for the target cloud platform.
The other two issues—data integration, and compliance and security—are less frequent causes of outright failures, but they are still big issues.
Not considering the data integration needs before migration means that you’re not going to find the issue before you can do anything to fix it quickly. In many instances, the latency between on-premises systems and the cloud can’t be corrected. In such cases, you need to move back to the data center—after declaring failure.
Compliance and security issues often require systemic changes to the applications and databases in the cloud, and so need a lot of upfront planning. In a worst case, you end up with compliance or security failures so grave that you must start over.
It’s important to understand that failure is a part of cloud migration; after all, most organizations are still learning. So expect mistakes and build the fact of failure into the migration efforts. But do more than that: Also make sure you learn from the failures and thus continuously improve your practices, tools, and skills.
