3 application modernization mistakes to avoid

Application modernization takes existing applications and data sets that run businesses and makes them more useful, productive, and attractive. As I stated before, some see application modernization as “putting lipstick on a pig,” but it should not just make applications appear modern, it should make them look and be modern. 

To that end, I see several mistakes being made that will have to be fixed at some point in the future. My advice to friends, colleagues, and clients: You really want to do this once. Don’t get something wrong the first time and then have to fix it down the line.

The trouble is most people don’t believe they will have to fix things in the future, and they make honest mistakes. They don’t understand the underlying value of app modernization and how it can be focused incorrectly.

Here are my top three application modernization mistakes in terms of applications that are migrating to the cloud or being modernized once there:

Not doing enough. Most applications move to the cloud by just lifting and shifting. Enterprises find an analog for their existing legacy “as is” platform on a public cloud and move the code and data there. Easy peasy.

This is often sold as the most cost-effective way to move to the cloud, considering that you’re doing the bare minimum. Complicating the problem, the cloud providers themselves often promote a lift-and-shift approach so that they get the revenue ASAP.

We’ve understood for years that applications that are not refactored to take advantage of the native features of a specific cloud provider are not optimized for that cloud platform and thus cost more to run. Issues often arise, including poor performance, poor user experiences, and lack of fundamentals such as native governance and security protections. The result is you’ll have to loop back at some point and fix those applications.

Doing too much? This isn’t as big of a problem as not doing enough, but it’s still an issue. Those doing application modernization apply the current religion of cloud-native development to all applications even where there is no clear business case. They are completely rebuilding most or all applications, typically using containers, microservices, and container orchestration to achieve an objective that never really needed to be achieved.

Not all applications need to be rebuilt from the ground up for the cloud. Some need partial refactoring, enough to ensure that the application is optimized for a cloud platform and takes advantage of native services such as security and performance management. However, there is no reason to toss the existing code and rebuild everything if there is no clear business case to go that far—and certainly not for all applications as a matter of policy without technical or business requirements.

Many are spending five times more than they need to for app modernization. You need to find a balance between doing too much and not doing enough.

Focusing too much on portability and avoiding lock-in. Being “cloud agnostic” is a battle cry I hear a lot these days. The principle is sound (avoiding locking an application into a specific cloud provider), but people think they must move heaven and earth to ensure that it does not happen.

This is really another way of doing too much. However, this time you’re rebuilding an application from the ground up, typically using containers or least-common-denominator coding schemes to build portable applications that will never, ever move off that one cloud provider—ever.

The reality is that portability and avoiding lock-in should be considered, but unless there is a compelling business case or technology reason for doing major surgery to an application on a cloud provider, you’re preparing for a day that will more than likely never come.

Again, you end up spending three to five times the time and the money, as well as increasing risk, to basically develop that application again. The odds are overwhelming that it will never need to move off the current public cloud host; thus, you’re wasting money that could be spent in other ways to benefit the business. 

I suspect that we’re spending about 50% more on application modernization than we need to right now. Time to work a bit smarter. You find good uses for that saved money, trust me.