When people first started migrating applications into the cloud the most popular strategy was to re-write them entirely for the cloud. The idea was that if you re-wrote the application, you could take full advantage of all the great cloud-native services offered. And, as a result, you would reap the benefits of the ultimate in agility, efficiency, cost, and scale. All of this sounded great on paper. In fact, it still does sound great on paper. But that’s the problem: it only works on paper. In reality, re-writing applications from the ground up is cloud migration Kryptonite.
How is it, though, that something that looks so good on paper ends up being so poor in reality? The simple gist of it is that re-writing an application, especially one that is complex, stateful, and multi-tiered, is challenging. There are a lot of moving pieces. And with those moving pieces, the likelihood of failure rises dramatically. And that’s usually exactly what happens: the re-write project simply fails. Let’s look at some of the most common challenges that result in application re-write failure.
Expertise: First and foremost, if you’re going to re-write an application from the ground up and integrate it with cloud services, then you need a lot of application-level expertise. You need someone who understands that application inside and out, and who’s properly documented it throughout the years so that the knowledge base is shareable and transferrable with the engineers who will do the coding. This is often not the reality though. In many cases, there is no application guru who knows exactly how or why it works, and there is almost never proper, up-to-date, clean documentation of that application for engineers to rely on. This results in an application re-write process where engineers are leading themselves in the dark.
Time: Let’s say you do have the knowledge base you need to pass along to the engineering team. That’s a great first step. But, now that you’ve got the knowledge, the engineers need to spend the time researching the cloud services, the integration points, breaking down the application, planning the re-architecting, re-writing the application, testing it, making modifications, and then ultimately launching and validating the application in the new cloud environment. That’s a lot of steps, and these project is going to take an extraordinary amount of time – sometimes years!
Cost: The heavy time commitment leads us to our next challenge: the budget. What does it cost to have a team of engineers working on an application re-write for two years? It’s pretty expensive. But, not only that, there is tremendous opportunity cost lost as well. Because while your engineering team was working on re-writing that application, they weren’t spending time working on the product your company sells. That means that your own software – your bread and butter – may have suffered a bit as a result during this long re-write project.
Data: In addition to the expertise, time, and cost challenges, you’ll also be faced with migrating a database that likely has terabytes worth of data. How do you smoothly migrate this crucial data into the cloud such that there is minimal app downtime, no data loss, and a smooth and transparent transition to the new cloud instance? It’s easier said than done, that’s for sure, which is why some companies end up having to run the legacy app on-prem indefinitely while the new cloud app runs in parallel. Sure, the new cloud app enjoys all the benefits of the cloud, but you’re paying for double infrastructure, double management, double maintenance – all of which adds up quick when you’re managing two unique instances of the same app.
Expectations: Even when an enterprise has a way to mitigate all of our previously challenges, there remains one which no one can truly prepare for: the unexpected. Yes, even the best laid plans will run into unforeseen challenges. Which means even an enterprise who could confidently tackle the expertise, the time, the cost, and the data… will not able to fully prepare for random roadblocks that may lurk around the corner. Sure, these unforeseen challenges can perhaps be addressed, but at the cost of more time and money being spent. Sometimes this means adding evermore months to an already year-long re-write project.
When all is said and done, re-writing an application for the cloud seems like a great idea, and a great way to really maximize the cloud benefits. But, in reality, it just doesn’t play out like that. Whatever extra benefits you earn through application re-writes were lost (and then some…) in the challenges that you faced to get there. For example, if tight cloud integration saves you $50,000/year, but you spent $1,000,000 on engineering resources to do the re-write, then you’re going to be paying that off for a long, long time!
That’s why enterprises are increasingly avoiding application re-write projects, and instead focusing on an approach that yields the benefits of the cloud but without the hurdles. Often referred to as “lift and shift++” (pronounced “lift and shift plus plus”), whereby applications are moved directly into the cloud mostly as-is, and then optimizations are performed directly in the cloud to achieve some additional benefits through the “low-hanging fruit”.
All-in-all, this strategy gets enterprises plenty of cloud benefits, but avoids all of the tremendous challenges that a re-write project would have required. So, if you’re thinking about an application re-write, give it some really careful thought and consideration. See if a lift-and-shift++ approach can accomplish most of your goals, but with dramatic time, cost, labor, and complexity savings.