From your perspective, things are crystal clear: migrating some of your crucial workloads to the cloud offers a chance to optimize computing costs, modernize your IT stack, and ultimately create smarter and more scalable business processes. Unfortunately, not everyone is always going to see it your way. Even as a CIO, getting enough stakeholder buy-in to get your cloud migration project off the ground—and keep it afloat even amid changing priorities and new business conditions—is non-negotiable.
This is where a strong cloud business case can come in. Some people think of business cases as complex, unwieldy documents that bore readers into a stupor—but with the right approach and the right information on your side, they can actually be powerful tools for getting ongoing support for your projects.
When it comes to cloud projects in particular, a strong business case can also be a unique opportunity to dispel common myths about the cloud and get everyone on the same page about what a migration project actually means and looks like. Not only can you lay out a compelling sketch of the business problems and challenges you expect the cloud to solve, you can also prepare stakeholders in advance for the timelines, costs, and capacity needs that a project like this will actually require—so that they don’t feel blindsided when the project isn’t done overnight.
What Is a Business Case, and Why Do You Need One?
On the simplest level, business cases differ from proposals in that they include a thorough justification for taking on a particular project, as well as a comprehensive evaluation of the financial ramifications, risks, and other business impacts. Without a document that lays out the risks and rewards in a coherent way like this, you run a huge risk that buy-in for your project will dry up before you’re finished, resulting in a wasteful array of sunk costs. Naturally, you’ll want to avoid this fate by establishing a business case proactively.
For something as complex as a cloud migration—which can involve thousands of individual tasks and months or years of work (if we’re talking about a full-on refactoring)—the trick is to present information that’s clear and gets straight to point without losing your audience. To do this, you’ll want to keep a few pieces of information front and center throughout:
- What is your goal for the project, and how does it relate to larger business goals (e.g. cost reduction, becoming more Agile or competitive, etc.)
- What’s preventing you from achieving those goals right now? (In other words, what’s the cost of inaction?)
- Why do you think that your proposal will solve the problem most effectively?
If you use these thoughts as your guiding principles throughout the document it will be much easier to contrast the modernization effort with the downsides of your current technology stack, or demonstrate the ways in which the new cloud-based technology will empower desired business improvements. Of course, you’ll have to pair this with careful cost-benefit analysis, but we’ll get to that in a minute…
Summary and Context
Now, let’s talk about what the business case should actually look like. You might be circulating at as a document once it’s been written out, or you might find yourself presenting it stakeholders as a PowerPoint or some other kind of presentation—but in either case the same basic structure applies:
- Summary and Context
- Financial Analysis
- Project Description
- Project Governance
The first section—summary and context—might actually be the section that you put together last, after you’ve gone through the ROI calculations, figured out your governance approach, etc. But when the time comes to write it down, the executive summary is going to be your best chance to grab stakeholders’ attention and convince them that your plan is the right one to serve your corporate goals.
With a cloud migration, your summary might be a page or two that hits a few key points:
- How your current technology stack increases costs, slows down work, decreases Agility, or presents any other sort of roadblock.
- How much change you think would be necessary to alleviate those roadblocks, and how the cloud fits into those changes, e.g. speeding up infrastructure, empowering DevOps, improving scalability, etc. Be as specific as you can while remaining succinct.
- What the risks and benefits are, and why you believe that the latter outweigh the former.
- How much, realistically, you expect the change to cost and what timeline do you expect for recouping your investment.
You want to be direct and straightforward with each of these, but, at the same time, don’t be afraid of couching the discussion in a larger vision of the future of your company.
When it comes to moving workloads to the cloud, financial calculations are often a little bit more complex than people imagine. We’ve written about how to calculate (and manage) cloud computing costs a couple of times already on the blog, but here’s a brief overview of how you might get started:
- Perform an inventory of workloads to be moved to the cloud.
- Based on that inventory, use a TCO calculator (like the ones provided by Microsoft and Amazon) to estimate your monthly costs for those workloads.
- Estimate labor costs for actually performing the migration. This can be difficult to do accurately for such a large and unwieldy task, but it’s crucial to at least have a decent estimate based on either historical data or counsel from an outside perspective.
- Consider costs for middleware and redundancies, plus labor for ongoing management, troubleshooting, etc.
- Outline cost levers for managing cloud computing costs, such as setting up reserve instances, right-sizing, and shutting off instances that aren’t in use.
- Sketch out potential cost optimizations that will be powered by your new cloud initiative. Will you be able to shorten cycle time for new software releases thanks to cloud-based infrastructure? Will improved data visibility make it easier to find and root out inefficiencies? You won’t necessarily have all the specific here right away, but it’s valuable to be as detailed as possible.
Lay all of these out as clearly as possible, then divide projected financial gain-minus initial investment by initial investment to get your projected ROI.
Of course, no one in any business has a crystal ball. There is always the risk that your estimates are wrong, the project takes longer than you expect, or business conditions change rapidly in a way that partially invalidates your analysis. Acknowledge this is this section by laying out risk factors and making an attempt to quantify them as best as you can.
Okay, this section might come relatively late in the business case itself, but it’s probably the first thing you should work on and iron out. We’ve talked about creating a cloud migration strategy document on this blog in the past, and much of the information that traditionally goes into a strategy document will also go into your business case. Namely:
- Your vision and goals for the initiative, with any background that the reader
- An inventory of workloads with a rundown of each one’s projected migration status (i.e. rehost, replatform, refactor, or phase out)
- Your larger technology roadmap, including what your current technology stack looks like and how you see it changing throughout and beyond the project.
Essentially, you should think of this section as your opportunity to flesh out anything in your summary that seems pertinent. Again, you don’t want to lose anyone’s attention with dry or boring information, but if you want to get into the weeds this is your opportunity. If you thoughts about specific solutions or techniques you want to utilize during or after your modernization efforts, if you have specific concerns with your existing stack that you expect the cloud to fix, lay that all out here.
Cloud governance is something else that’s typically covered in a cloud strategy document, but it’s important to include in your business case as well. Why? Because it shows that the plan has really been thought out, and it can help you overcome any specific tactical objections that the reader or listener might be thinking of. This will include things like:
- Who’s in charge of change and risk management?
- Who has the responsibility to manage the cost levers we discussed?
- What will the vendor selection process look like?
- How will you designate a cloud architect?
- What’s your capacity plan?
- What steps will you take towards security and compliance for any data that’s being moved?
- What are the principles of your desired cloud architecture?
- How, exactly, will you measure success or failure?
- What criteria will you use to make the go-no-go decision at the appropriate time?
Again, this is a chance to prove that you’ve done your homework. In all likelihood, there will be a lot to say in this section, even once you’ve covered all of the items that we listed out above. As with previous sections, it’s important to remember that you’re trying to keep the attention of your audience and present a strong case.
This all might seem like a lot to figure out—but it’s only a fraction of what you’re going to need for all but the simplest of cloud migrations. And if that cloud migration forms a part of your larger digital transformation, there will be even more to consider as you continue to work towards your goals. To be sure, the thing we’re describing requires a level of cloud knowledge and expertise that most businesses simply don’t have in-house. Luckily, you don’t have to go it alone—even in early stages like putting together a business case. You can turn to trusted cloud migration experts to get a knowledgeable and experienced viewpoint.
Learn More About Intertec's Cloud Solutions:
Intertec’s teams have hands-on experience in developing and migrating applications on leading cloud platforms. In addition to design and development, we provide a complete range of application testing, deployment and ongoing support services, including managing physical infrastructure and offering outsourced DevOps teams. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!