It can take anywhere from a day to two months to move a workload or application to the public cloud. This has been so tough to predict that a few niche consulting firms, public cloud providers, and thought leadership dudes (like me) think they can successfully model this within a few percentages of what it will actually cost and how long it will take.
While this is a nice idea, the reality is that a few things can’t be easily modeled, such as bad application and data architecture.
Almost all of the application workloads and data sets that I migrate to cloud look like they have been designed by committees—and in some cases they have. They are not capable of scaling or using the databases correctly, and worse, the databases are designed so badly that they hold redundant data, are not properly indexed, and are tightly coupled to the application itself. Sound familiar?
There is a right way to move to the cloud and a wrong way. The right way is to fix all architectural issues before migration, which means weeks or months of redevelopment, retesting, and redeployment. Or you can push the code and data to the cloud, lift and shift, and hope for the best. This never works long-term, by the way.
The trouble with migration estimation metrics is that they never consider awful architectures. They may estimate two weeks when you really need two months. The application owners are asked to provide the underlying architectural information; often they are too close to the application to make a sound assessment or be self-critical. In some cases, tossing the original and starting from scratch is really the best option.
Although there are indeed code analyzers and database analyzers, I’ve found that they typically say there’s a problem, but they don’t say what the problem is or how easy it is to correct.
This is the main reason you can’t size migration well, but it’s not the only one. Other less-annoying issues include bad security hooks, systemic performance problems, and overused resources. Unfortunately these take longer to fix than you likely understand, but ignore them and migrate at your peril. The results can be catastrophic.
Are there any good ways to estimate the cost and time to migrate applications and data? Today it requires a skilled, in-the-know cloud application architect to lead the way. That’s as much of a break as you’ll get.