The Fatal Mistake Companies Make with Their Cloud Migration
Migrating to the cloud is a commitment. It’s a commitment of time, resources, and corporate energy.
Perhaps you are migrating an on-premises application to the cloud. Or maybe you’re moving a monolithic application to service-oriented or microservice architecture. Migrations are not easy to pull off, and can involve long transitions. Because the benefit is not always immediately obvious—and, in fact, sometimes things get worse at the beginning—it’s tempting to want to quit the migration early.
Who would ever want to do that? It seems crazy, but it happens. Moving from a monolith to a service architecture, but stopping soon after the migration has begun, leaves the application in worse shape than it was before starting the migration.
So how do you avoid the temptation of halting a migration in its tracks? Well, the key to avoiding this cloud migration mistake is all about managing expectations and understanding the true return on investment.
The Valley of Pain
When we start a major migration, especially a complex migration such as a monolith to microservices migration, we have certain expectations about the benefits we will ultimately see. We expect the benefits are a function of the effort and time we put into that migration. We calculate that the ROI will make the effort of the migration worthwhile.
But this ends up being a simplistic view into determining the value and benefit of the migration. A simple ROI calculation doesn’t sufficiently capture our understanding of how our efforts will turn into benefits. Typically, we imagine the benefits and investment will play out uniformly over time, as shown in Figure 1.
As time goes on and we continue our investment in the migration, we expect that the benefits we receive, either real or perceived, will continue to increase. The more effort and time we put in, the more benefit we receive—or so we think.
In reality, this idealistic model isn’t representative of how a cloud migration normally works. The relationship between investment and benefit will often be a lot more complex and will look more like Figure 2.
Here, the initial investment appears not to have much benefit. In fact, we may actually see no early benefits as things get worse initially. Only as time goes on will the real benefits begin to emerge.
Let’s consider an example. Imagine you are moving a monolith to a service-oriented architecture. Initially, as you start changing parts of the monolith over to services, you might experience decreased performance. The application complexity increases because your application contains many more moving parts. You continue to add more individual services to your application, yet still the remains of the monolith are present and are heavily involved in the function of the application. This complexity may cause reliability and scaling problems, or it may create other unforeseen problems.
In short, your application may be worse off than it was before you began the migration. There are several reasons why this happens:
- Your code is in an interim state, with added technical debt related to the migration.
- Your code runs slower because some code has been updated and some code has not.
- Your code is more difficult to understand because some code uses the old paradigm and some uses the new paradigm.
The code is, frankly, a mess.
But as time goes on, you work your way out of this low point, and the benefits of the migration effort begin to kick in. Your benefits multiply. You will start seeing a return on your effort as service creation becomes easier and takes over more functionality from the monolith. The growth of benefits over time will accelerate. Finally, you will see the actual value of the migration.
But to see these benefits, you have to make it through the low points of the early days of the migration. You have to make it through what I call the Valley of Pain.
There is a strong tendency to want to give up on the migration in this valley. After all, you’ve invested in the migration, and you haven’t seen any benefits. Instead, things have gotten even worse than they were before.
But don’t make that common cloud migration mistake and give up here. Don’t stop the migration at this point. If you stick with the migration just a little bit longer, you’ll begin to see the benefits come through. Eventually, you’ll make it to the point where the benefits are growing faster than the effort you are putting in.
Falling for this trap
I’ve been through many cloud migrations. Virtually all of them experience the Valley of Pain. Unfortunately, companies fall into the trap of giving up at this low point and suffer the consequences of this cloud migration mistake.
One major company I worked with abandoned their monolith migration at the worst possible time—at the very bottom of the valley. In doing so, they simply “declared victory.” But there was no victory to be had.
They informed everyone working on the project that they all had “learned enough” from the painful migration effort: “We now know what’s involved in implementing this migration, so we can stop here and maybe pick the migration back up again later on.”
The company wanted to get back to doing “real work” and stop investing in the migration. They concluded the announcement by telling everyone, “This exercise was a valuable experience, don’t you think?” Yes, it was a valuable experience, but at what cost?
What the company had created was an untenable code base. They had built several services that were figuratively bolted on to the side of the remaining monolith. Yet, the monolith was still there and still just as difficult to work on. Their code was a mess, and they suffered from the problems caused by this mess for many years.
This costly cloud migration mistake of deciding to stop the migration severely reduced the company’s ability to produce new features. Morale among the engineering team hit an all-time low, and the company lost many good engineers. They even created some severe availability issues that impacted customer satisfaction. This was not a pleasant environment to work in at the time.
The lesson from this story is this: The relationship between benefits and effort is not linear when you migrate to the cloud. There will be times during the migration when things seem to be getting worse rather than better. But don’t give up! There’s light at the end of the tunnel, and the benefits will begin to appear. And those benefits will be more than worthwhile in the long run.
More from Lee Atchison: