“No bucks, no Buck Rodgers,” is a quote from the movie The Right Stuff. It comes to mind every time I see IT people attempt to do great things with technology on the cheap.
Don’t get me wrong, I don’t advocate overspending on technology, and certainly not for cloud computing. However, there is a specific level of resources you need to make cloud computing work for your enterprise. The key is to identify that goal post and then figure out how to get it funded.
Speaking in generalities, the staff most knowledgeable about cloud computing usually have the least experience putting a project plan together or playing office politics. For a variety of reasons, they often make cost projection errors for the cloud projects they promote, thus their project falls short or fails altogether. Typically, the cost to fix the failed project is double the cost if it had been done right the first time.
For an enterprise’s first few cloud migration projects, the problems are not entirely anyone’s fault. The staff is often trying to figure out the details of a conversion process they have never encountered in their careers and create a plan for a project that has never been done within the enterprise. Details get overlooked, and the forecast of $10 million to migrate 20% of the enterprise’s applications from the private data center to the public cloud comes in with a much different price tag. They just don’t have the experience and existing metrics to draw upon at the planning and implementation stages.
That’s why any new technology requires some leaps of faith. If a vendor skirted the truth, or if some technology did not meet expectations, you would need time and money to fix those issues. “Unanticipated costs” is a frequent line item on cloud project reports these days.
So, how can you get leadership to fund a realistic cloud migration budget?
Successful migration of apps and data to the cloud comes down to planning and taking the most common contingencies into account. If you’re new to cloud migrations, this is the time to lean on the skills of consultants or employees who understand what technology it takes to migrate to a cloud platform. You also need to understand the existing “as is” state of applications and data within your enterprise and the true cost of skills and time. Then you can model the migration in realistic ways. This includes adjustment plans for the unanticipated costs that arise with every enterprise’s first few cloud migrations.
The trick is to provide realistic budget models that are provable with existing data.
Now that we’re 10 years into cloud computing as an industry, we know how much it will cost to migrate an application with 1,000 function points and a medium-complex database when there are platform analogs that exist in the target clouds. Refactoring 50% of the applications? Add more funding. Moving from a traditional relational database to a cloud-native object database? Add more funding.
If you don’t know where to start, use lift-and-shift costs as a base and add to it as you find additional work and technology that’s needed. The planning process might reveal hidden lift-and-shift costs that make a net-new cloud migration more feasible for certain apps and/or data.
The end state should be a model of how the migration will be done. The model should answer these questions: What technology will be employed? How much time will each workload need? What is the cost of required on-premises tools? What cloud tools are needed? Are specialized skills required? Are improvements needed in areas such as security? You get the idea. Detail this list to the point that you can model changes to funding, including increased risk and costs in the years ahead.
Do this model the right way and it’s easy to show the impacts of adjustments to funding, which is a common request. The model becomes the easiest way to find the optimal funding for the cloud project. Does the board or your boss want to decrease funding? This is the impact. Same with increasing funding.
Let’s say the board needs to remove $3 million from the budget. The model will illustrate the reduced number of applications and data sets you can migrate, as well as the increased risk for a certain percentage, and increased operational costs on the outyears.
Conversely, the model can show the impact of increasing the budget beyond what is needed, which should include a point where spending more money flattens the benefit curve for the project. You need to show that you understand both extremes and find the right compromise and points of budget optimization.
Once this is done, it’s no longer a negotiation. It’s dealing with a model that represents the way the project should be carried out, including resources needed and how to use those resources to optimize the benefit to the business. It’s showing how the project will suffer from too many or not enough resources.
Take your time and prepare the best project model before you ask for a dime of funding, and your cloud budget can be maxed out to everyone’s benefit. The requirements and consequences are all there in black and white.