Tips, examples & fill-in format
The benefits of Cloud are probably very clear to you. You know your company’s application landscape and suspect that a cloud migration will free up a lot of time and budget for innovation. Nevertheless, it is useful to convert your suspicions into concrete predictions in the form of a business case. In this you compare the current costs against future costs and benefits, and you calculate the investments required for the transition itself. This way you can paint a reliable picture of the new situation before the cloud migration. This is useful for several reasons. For example, your company’s so-called C-suite must gain confidence in your plans and support you with time and the right people. You also need figures for a good negotiating position with your future cloud provider. But the most important reason to make a business case is still to answer that one question: “Is the Cloud going to give us the right results?”
What is a business case?
With a business case you calculate the financial consequences of your cloud movements (see image below). What happens if you replace an application in your on-premises data center with, for example, a SaaS service? Which costs will then be eliminated and which will be added? For example, you have to pay costs for the maintenance of an application in your own data center for physical infrastructure, licenses and maintenance, but you also pay costs for the same application if you migrate it to a public cloud. The more complete this cost calculation, the better. This isn’t a small piece of work, especially when it comes to current costs. For example, for some applications you have to do extra research to make connections between all sources of information. It’s important to make time for this. If you make an estimate for every possible cost item, you will be faced with fewer surprises later in the process.

Calculation of current costs
First of all, you’ll need to map out the costs that you’re currently spend on IT. In some cases, you should make this incredibly detailed: for example, how many hard disks do you have per server and how many hours do employees spend on managing a particular application? The need for such an in-depth analysis differs per situation. In some cases, extensive analysis misses the mark and delays rather than enlightens. We call this phenomenon analysis paralysis. This means that you keep analyzing the information you have endlessly and do not rest until you are aware of everything you have in detail. Often it is sufficient to work with standard units such as average capacity of a server. You can also use benchmark data: information about what the costs look like at comparable organisations. For example, the average costs for a server, including management, are around $6000 per year. You can use that benchmark data to include the missing data in your calculations.
To keep things clear, it is wise to divide the costs into a number of layers and only zoom in further if necessary:
- Infrastructure
Think of any depreciation, periodic server costs, platform licenses (such as VMware) and costs for maintenance and management. - Software & license fees
Think of the purchase of software, licenses (for example for SQL). - Technical and functional application management
Think of executing scripts, updates/upgrades and technical application management. This also includes adding users, adjusting access rights and providing training. - Software development
Think of the man-hours you lose to develop custom software. This is happening more and more in DevOps teams, where team members both write new code and take care of operations (execution and support).

How do you build the financial model?
Once you have mapped out your current situation, you calculate the impact of the transition to the Cloud for each layer and analyze the expected savings. Then calculate the costs required for the transition itself and you’ll know how much money is needed to make your expected savings a reality. For IaaS (and to some extent PaaS), the new costs are fairly easy to calculate using online calculators such as those from AWS and Azure, and the costs per SaaS product are easy to find out. You’ll often have to contact the SaaS supplier, and a quote can take a while to receive. The transition costs (ie the costs of the migration) are a lot more difficult to calculate, but in general the bandwidth is between 2,000 and 3,500 per server to be migrated. As soon as you have received all concrete numbers, enter them on a sheet as in the example below.
What do you do with the results?
Based on your business case, you determine whether a cloud migration is financially interesting in the short and longer term. In addition, as mentioned, you can include the business case in negotiations with your cloud provider. But even after signing the contract, the business case will pay off. Because you have calculated the costs down to the application level, you immediately see where the quick wins are. For example, the SaaSing of one server can save you a lot of money in the short term, while the migration of another will take a lot of time and effort. You can also set priorities based on the predetermined goals. For example, if one of the business goals was to standardise as much as possible, you could choose to spend the first three months offloading as many applications as possible and replacing them with a SaaS product. This way you spread both the budget and the load per department and at the same time act in line with the company goals.
We hope we gave you enough information to start your own business case. Would you like to know more about the road to a solid cloud approach and how to arrange the selection and relocation of applications?
Download “The down-to-earth approach for IT managers“, our no-nonsense guide that will help you properly prepare for your cloud transition.
