fbpx
skip to Main Content

sap migration to awsIf you’re thinking of moving some or all of your SAP landscape to the public cloud, Amazon Web Services (AWS) is a worthy choice. They have multiple options for SAP in the public cloud. In addition to preset SAP solution packages, AWS is providing bigger instances, more extensive customization and automation, improved stability and better third-party support. It’s not an easy decision, though. While it is becoming harder to justify the cost of running a data center, putting SAP onto AWS is not without its challenges. Having worked with many clients on SAP migration to AWS, though, we can recommend best practices that help ensure a smooth transition.

SAP Migration to AWS Overview

Migrating SAP to AWS is going to be a major transformation, no matter how simple it may look at the outset. The process involves moving your most business-critical assets to a hosting platform you don’t completely control. You’ll be in a multi-tenant environment, and own the responsibility for architecting a high-performing, redundant SAP landscape.

Before you dive in headfirst, it’s worth asking yourself why you’re contemplating an SAP migration to AWS. Do you want to consolidate your SAP assets in the public cloud to gain operational efficiency? Is it a risk mitigation move? Is it part of an SAP upgrade?

Your migration should align with your broader SAP goals and overall cloud strategy. It doesn’t matter if you’re doing a “lift and shift,” a backend database migration or a full SAP S/4HANA upgrade. Each has its own complex considerations. Working with a partner can help. A partner who’s been through it before can work with you throughout the process—all the way from identifying goals to choosing a migration strategy, handling the migration itself, making the transition to steady-state operation and performing the ongoing maintenance and support that is required.

A Recommended First Step: AWS for SAP HANA

It’s usually a wise move to start with a move from SAP ECC or SoH to SAP HANA.  This way you can focus on the back end database migration first. Deal with the front end application at a later stage of your migration project. This way, you can clean up your data and code, realizing database efficiencies without changing the business processes. Then, you can plan to upgrade to S/4HANA on AWS.

At the same time, certain qualities that make SAP HANA innovative can make it more complicated in the public cloud. As an in-memory database, SAP HANA requires a significant amount of dedicated RAM in order to function property. AWS has special  virtual instances specifically designed and certified to support HANA workloads, but right sizing these systems, and eventually tight sizing these systems is not typically as cut and dry as you may think.  This is where the value in both public cloud and SAP expertise really comes into play.

SAP on AWS Implementation Guide

Running SAP on AWS is more than just a change in your hosting provider. It’s really an entirely new phase of SAP operations. Remember—AWS is just a platform. You’re still in charge of your SAP landscape and responsible for how it works. AWS is infrastructure. As they themselves will tell you in their SAP FAQ, “AWS manages the physical infrastructure up to the virtualization layer. The operating system and any SAP applications and databases running above the virtualization layer are managed by the customer.”

In our case, we approach SAP on AWS as if it were in a private cloud. For instance, if something goes wrong with a VM, we shift workloads away from it. We transfer new workloads to a different VM. However, we keep the VMs operating long enough to avoid any disruptions. We’re also proactive about performance tuning and monitoring so your organization doesn’t miss a step. We leverage all that the public cloud offers while still maintaining eyes on the screen and hands on the keyboard. After all, this is SAP we are talking about.

SAP AWS Migration Steps

Each migration of SAP to AWS will be slightly different, so it doesn’t make sense to lay out an elaborate recipe here. Rather, it’s worthwhile to review the major migration steps that almost every SAP migration to AWS has in common.

  • Planning, including extensive gathering and review of technical and business requirements, details for personnel assignments and roles for partner firms
  • Architecting the solution on AWS, including failover and backup along with VM memory and processor configurations
  • For some, building a proof of concept environment, followed by testing, and “lessons learned” evaluation
  • Preparing existing SAP assets for migration, including data cleanup and modifications to the existing application code required for cloud hosting
  • Building your AWS Landing Zone
  • Installing, configuring and deploying SAP on AWS, including the all-important “go live” moment when you roll the old system over to the cloud
  • Mapping out and then implementing security and disaster recovery plans
  • Taking over Basis in the new landscape
  • Running Governance Risk Management and Compliance, e.g. Segregation of Duties (SoD)

Best Practices

Best practices for SAP on AWS include many of the best practices for running SAP anywhere. For AWS in particular, though, a few distinct practices are worthwhile to pursue:

  • Create a dedicated AWS support team, or at least a dedicated AWS person in your IT department. AWS is extensive and complex enough that someone will need to master all of its workings and stay on top of the continual changes that affect the platform.
  • Implement daily maintenance. Steady state SAP Basis operation doesn’t stop in the cloud. If anything, it becomes more urgently needed.
  • Pay attention to performance tuning. SAP performance tuning is critical to keeping your landscape healthy in the public cloud. Things can change quickly in AWS, as new tenant “neighbors” can affect the way AWS’s internal networks and server loads function.
  • Keep people in touch with each other, especially if you are continuing to run some of your SAP landscape on premises or in a private cloud. More deployments and connections create a greater need for communication and coordination between people and teams. Missing this practice is a common pitfall we have seen. Poor communication and internal coordination can lead to trouble with your SAP on AWS deployment.
  • Consider having one vendor to hold everyone and everything together. This is a role we are accustomed to playing.

Working with the Right Partner for SAP on AWS

It pays to work with a good AWS partner when performing an SAP migration to AWS, one that has a depth of talent among its SAP consultants. These people should be SAP certified, with the company part of the AWS Partner Network. For example, SAP HANA is sensitive to configuration and performance nuances in both hardware and network. Generally, you cannot fix problems with SAP HANA on AWS by spinning up more VMs. To get the best results, your partner should offer application performance monitoring capabilities along with appropriate management tools.

Similarly, watch out for limited or overly reactive service offerings. Sometimes, a company moving SAP to AWS will select a partner with a “Break/Fix” approach to support. The problem with Break/Fix is that the service provider waits until there’s a problem, causing delays as they figure out how to solve it. Sometimes the people at the service provider take an excessively long time to solve the problem because they’re not familiar with your AWS instance of SAP, lack training or both. This can be highly disruptive and costly to an organization. The right partner for running SAP on AWS should ideally have a dedicated team that’s continually maintaining and tuning your landscape.

We have extensive experience helping companies migrate SAP to AWS, or even helping them choose not to, if that’s the right call. If you want an expert opinion on AWS as an option for your SAP landscape, and then proven experience in rolling out the migration and post go-live support, let’s talk today.

Jay Graboff, Cloud Product Manager

Jay Graboff is a Senior Cloud Product Manager that has been evangelizing innovation and digital transformation before there was either. With over 8 years delivering Public, Private and Proprietary Cloud, his passion and love affair with technology is rooted in what the Cloud can enable.