I get this question all the time: How long will it take to move a certain number of applications to the cloud? Of course, they get the standard consultant answer: “It depends.”
But there are some rules of thumb that you can apply to get a general understanding how much work will be involved to make the migration. These rules of thumb deal with function and object points, complexity, data coupling, and use of cloud-native features.
Many enterprises look to move applications without modification, aka “lift and shift.” This means you can’t take advantage of cloud-native features, such as identity management, asset management, or governance, but you’re willing to sacrifice cloud-native for speed.
If you go in this direction, which is not always the best, it will take you about two to three days with two or three developers and DBAs to port the code and the data. Multiply that by 100, subtract the time improvements as you learn, and you’ll get 100 workloads into the public cloud in about 200 days, give or take a week.
However, if you decide to refactor, or rebuild, the application to be cloud-native, your metrics are different. You need to consider how much of the applications is likely to be refactored (as a percentage), as well as the complexity of doing so.
As a rule of thumb, the higher the percentage of the application that needs to be refactored, the more time it will take. I use one week per 10 percent, so if you’re refactoring 30 percent of an application to be cloud-native on a public cloud, that’s three weeks. If you multiply that times 100, that’s 300 weeks.
Of course, you can do most of this work in parallel if you apply more resources, to reduce that time well below 100 days or 300 weeks, as the case may be. It just takes more money and more risk.
And don’t forget that many other things come to bear as well, including how the application is designed, the coupling of the database, the type of databases, … the list goes on.
Those questions need answers, but we live in a world where people like sound bites for problem solving. Until you’re in a position to get accurate metrics, rules of thumb can provide such generalized “sound bite” answers to budgeting questions. Just remember: The devil is still in the details.