Setting the Business Case for Migrating SAP to AWS

Migrating SAP to AWS: Making the Case for a Strong Business Case

Without a proper business case, many Cloud migration projects simply don’t get off the ground. But the truth is, most organizations simply don’t know what the business case is, or at least have an extremely simplistic view that lifting and shifting their IT estate into the Cloud will just allow them to do things cheaper, faster, better. This may be a good marketing slogan, but it does little to help set a business case that meets the demands of the business.

Looking at a Cloud migration project as simply giving you the cheapest bit of kit undermines the broader benefits. While cost reduction is doubtless a by-product of Cloud migration, to focus solely on that as an output probably misses 80% of the business case.

Here, we offer a look at some of the big benefits of running SAP in the Cloud:

• One of the common mistakes often made is to think of Cloud as just another datacentre – and that the objective is just to get ‘to the Cloud’. In reality, this is only the start. A Cloud migration project is the chance to transform the IT estate, providing some re-architecture opportunities straight off the bat. These can be pretty simple things, such as setting up FTP services, which in AWS can simply be run as an SFTP service instead, removing the cost of installing, maintaining, patching, and so on. There is also load balancing technology that could be replaced, as well as adding automation to create services to replace some install software. More complex things might involve not just archiving but doing data tiering with SAP S/4HANA to remove cost, along with backup strategies and storage strategies.

 
Organizations going on this journey must therefore evaluate their SAP estate, how they are using it currently and how they want it to run in the future. This will enable them to set meaningful SLAs that can be monitored post-migration. The fear is that people simply view success as “now they are in the Cloud” rather than looking beyond that.

• People move to the Cloud for different reasons, of course, but there is no doubt they understand the cost-saving, if only from a list price point of view. You can’t do anything in the enterprise space without there being a business case, so this is obviously a big driver. But, when you get a bit more experience doing this, you see that cost savings are only really the start of the journey. Many businesses never realize the savings they anticipated because they don’t know how to manage spend in the Cloud.
   
  Variable spend is an amazing benefit but it requires new skills, which can mean organizations end up with a considerable bill. While DevOps, and DevSecOps, have grown in prominence, it needs to be a case of DevSecFinOps, where financial awareness is baked into everything an organization does. Whenever you provision something on Cloud, you are actually procuring something in the Cloud. Organizations need to be aware of this and build it into their change processes, whether doing automated releases or whatever else, financial processes must be properly embedded into this. This is a very different skill set to a techie who is good at coding. They need to understand not only the cost of a server but whether this the optimal way to buy a server, is there a savings plan, should you use dedicated hosts, and so on. There is a range of contracting options that are in themselves something of a discipline – and become a core part of the technologist’s skillset. Many techies simply won’t be interested in this stuff, but you can’t ignore it.
• Make no mistake about it, running SAP is complicated and, if not done properly, expensive. The ability to enhance clustering and monitoring in the Cloud, for example, are just some of the tangible benefits the business will enjoy. Ultimately, part of the reason SAP has a reputation for being slow and expensive is not the software itself, but because it is such an important system. It is the heartbeat of enterprises and people get very cautious about making mistakes with change. Those changes tend to be made by hand and, due to natural error rates, people put test systems in place before production to stop defects from getting through. A lot of noise and cost comes from trying to mitigate this defect risk.
   
  Cloud is a commodity kit, which is standard, meaning more people will be familiar with what the organization is using. Alongside this, automation replaces manual activity and is by definition more reliable. There can be bugs in the software of course, but a consistent software defect is much easier to manage than a random manual one. By removing noise from the landscape, things become much simpler and quicker. Once this has been achieved, the cost benefits and agility really come through. For example, if you can do a system refresh in three hours, why not do it every day?
• The side effect of automation is speed, but this must be done as part of a broader change of IT processes. There is no point doing a system refresh in three hours, but still requiring a manual sign off which takes three days. By looking at the manual tasks that take time and resources, it is far easier to automate in the Cloud which improves operational resilience and vastly reduces downtime.
   
  The real big benefit from agility is innovation, both within SAP and in non-SAP services integrated into SAP, which becomes very exciting. However, you cannot innovate without being agile, and you cannot be agile without automation.

The trap that many organizations fall into is focussing solely on migration, but not operation. This means that while the actual move to the Cloud may have been a success – as a pure lift and shift can be easy to achieve – this approach will never fulfill the business case. Organizations looking to move to the Cloud must focus more on the operation phase, looking at what they want to modernize in their SAP estate and the SLAs that are important, and then finally really looking at how they can achieve it.

Have you been through an SAP Cloud migration project? What did you learn from the experience and what advice do you have for those about to embark on such a journey? To offer your opinion, click here.