Migrating Your SAP systems to the Public Cloud: What you NEED to Know BEFORE You Start!

The decision is final, you are migrating your SAP systems to the public cloud, simple right?… Maybe. Do you really know what need to migrate? Well, what servers and applications make up your SAP landscape? Do you have accurate SAP landscape diagrams that you can trust, and do they tell the whole story about how traffic and data move in or out of your current environment? Is the whole environment moving or just a portion of it, and are your moving more than just systems that you consider to be part of the SAP landscape? What about networking and security?  

These are just a few of the many questions that will make you lose sleep as you begin planning your cloud migration. This blog post will explore answers to all of these questions and more to ensure your SAP migration to the cloud is smooth.  

Where to Start – Your Current SAP Infrastructure 

If you’ve already thought about all these things and have this information prepared, then you get a gold star! If you haven’t secured answers to these questions, make sure that you are start talking with your SAP technical and functional teams in additional to your IT infrastructure and network teams as soon as possible. 

If you are migrating out of a data center that you don’t own, ensure that you have notified your hosting provider ASAP so the shell shock of them losing your hosting business has a chance to wear off. This is a critical step that must be done so that contractual details can be worked out and resources from your hosting partner can be scheduled to support your migration project. Breaking up is hard to do, but you’ll be better for it! 

Now, ask yourself how much help you’re going to need to pull off a project of this magnitude. If you’re hosting your systems on-premise, you are already focused on hosting servers and all the good stuff that goes with that responsibility. Things like, SLAs, DevOps, backups, Disaster Recovery, High Availability, and the list goes on. However, does your infrastructure team have the necessary training and gumption to migrate and support your company’s most critical SAP applications into the public cloud? If you aren’t already hosting your systems on-premise or the answer to this question is “No” or “Hmm…” then it would be a good idea to start talking to a certified public cloud partner like Protera. 

Where does Your SAP Basis Support Factor in? 

Ok you’ve thought about infrastructure, now what about SAP Basis? Did your previous hosting provider also provide SAP Basis managed services and are you losing those services? The same question applies… does your SAP Basis team have the necessary and certified training to migrate and support your company’s most critical SAP applications into the public cloud? Protera’s expertise offers a unique pairing of cloud and SAP Basis experts that understand how to run and manage SAP landscapes on a public cloud platform! 

Now your technical planning can begin – here is a short list of other heartburn inducing topics: 

• Are your current SAP systems supported in the public cloud? Do you need to perform an SAP patch, upgrade or OS/DB switch? 

• SAP has certified combinations of SAP applications, OS and DB versions that they’ll support in the public cloud. 

• Determining if your existing systems fall into what is supported will influence the methods used for migration. 

• What method(s) are going to be leveraged to migrate your systems? Hint: In most case you’ll leverage multiple methods 

• Importing a VM – Take the whole existing VM from your hosting provider (good luck with this!) or on-premises datacenter. Consider this as close to a true “lift and shift” approach that can be possible when moving to a public cloud platform. As an example, Google Cloud supports importing systems from on-premise, AWS or Azure through Anthos. 

• DB replication – If SAP and the public cloud support your current database, you could use your database’s native system replication methods to get your data into the public cloud and minimize your cutover downtime requirement. You may choose to replicate your database onto freshly installed DB servers or deploy an approach that also involves importing VMs from your on-premises DB and application servers to “seed” the new public cloud environment. 

• SAP tools – If your SAP version, OS or DB aren’t supported in the public cloud or you are planning to upgrade SAP and change your OS or DB then you and your project team partners will need to determine how to make the migration possible. This will most likely mean that an OS/DB migration or SAP upgrade + migration will be required. For this, SAP’s Software Provisioning Manager (SWPM) or Software Update Manager (SUM) – Database Migration Option (DMO) will be used. 

• When using SAP tools, you are basically rebuilding your current environment in the public cloud from the ground up. For this method to be successful you need to know your environment extremely well and it helps if it is documented in detail. For example, you may need to recreate new shell scripts to replace Windows batch or PowerShell scripts if you are moving from Windows to Linux or vice versa. You may need to account for custom directories used for file exchange or staging between systems or applications and any other data that lives alongside the SAP instances. SAP tools only account for SAP standard filesystems and customers are responsible for their own directories. If the migration to the public cloud is being bundled with an SAP upgrade, then there is also a plethora of considerations that go along with that. Without getting into details, an upgrade will require review of existing add-ons, customizations, and integrations which are all things that an experienced SAP Basis project team (such as Protera) can guide you through. 

• If you have many SAP landscapes and systems, do you migrate one landscape at a time or aim to do all landscapes at once? 

• If possible, keep things simple and don’t bite off more than you can chew. However, if you split the migration into chunks, make sure that your network connectivity can support bandwidth requirements between migrated systems and those remaining in the original datacenters. A “Big Bang” approach is also possible but requires extremely detailed cutover planning. 

•  How do you plan on handling change control in SAP? 

• Ideally, you’d freeze all changes and eliminate this requirement. In the real world your development system will be migrated first and you’ll either have two development systems – one in the public cloud and one in the original datacenter or you’ll shut down your original development server and only have the new system in the public cloud. In either case you have hurdles to overcome with how changes will move through the SAP landscape while the migration is in progress. 

How much downtime can the business tolerate for each application being migrated? 

• This will become a huge factor in influencing many other decisions that will need to be made and only your business knows this answer! 

How do you plan to get your data to the public cloud once its exported or backed up? 

• Can you establish speed connectivity between your on-premises or hosting providers network to transfer data from server-to-server? 

• Can you utilize a high bandwidth Internet upload to transfer data into a Cloud Storage Bucket? 

• You can’t just drive a NAS device up to a public cloud datacenter and ask their “smart hands” to plug it into your environment. The physical vessel for your data into a public cloud datacenter is limited to a Public Cloud Transfer Appliance. Using this option requires additional cost consideration, understating of timings and orchestration of human datacenter resources and shipping partners. 

• Don’t forget about… 

• Engaging global business process owners early on so they can begin planning for the scope of testing. 

• To test printing or migrate print servers. 

• To consider interfaces such as tax, fax, email, document storage/archival, encryption services, etc. You may need to re-install these interfaces and plan a migration of each of them in addition to your core SAP server migrations. 

• Review your external access requirements. Your existing environment may allow connections in from the Internet by way of a public DNS records, firewall rules (NAT) and reverse proxies such as SAP Web Dispatcher. These will need to be replicated in the new public cloud environment. 

• Hostname changes and IP address changes. DNS records will need to be created or updated and configuration between SAP applications may need to be updated to reflect hostname and IP address changes. This will also require updates to SAP GUI connections on each user workstation and bookmarks in browsers. 

Key Considerations for Your SAP Migration to the Public Cloud 

Up to this point, we’ve just covered the usual pain points and topics involved with your average run-of-the-mill SAP landscape migration. Most of this isn’t unique to an SAP migration, so what are some key considerations specific to a public cloud migration? Here is a taste of common challenges: 

• Network Connectivity between the public cloud and customer sites such as datacenters, corporate offices, branch offices, field locations, warehouses, etc. If your existing on-prem systems or systems at your hosting provider have access to a location this means that your systems in the public cloud will also need to have access to these same locations. If you have low tolerance for downtime during your cloud migration then your best bet is to ensure that you have either a fast connection to the public cloud from your existing datacenter or you have a fast Internet upload speed from your existing datacenter. If you are currently in a hosting provider’s datacenter, you’ll also need to make sure that the network connectivity between your on-premises networks are ready for the new public cloud connectivity. For this, you should consider implementing a Cloud Interconnect and VPN connections (for redundancy). Try to get network decisions made with plenty of lead time because telco providers are slow, and they don’t speed up for anyone or anything. Expect delays and build “fudge” time into your project plans. 

• Network Security is a blank slate when you initially create a VPC in the new public cloud platform. To ensure the that are protecting your systems, you must take precautions to ensure that your firewall ingress/egress rules are maintained in the most stringent way possible. Your certified public cloud partner can help ensure that you are securing your systems through your public cloud firewall rules. 

• Security (Identity and Access Management) in the public cloud can be complex. No this is not SAP level application server, that doesn’t change from what you’re used to. Most public clouds, provides a menu of services and products that are used together to accomplish your wildest IT dreams. As you can imagine there is great power involved in being able to modify networks, provision compute, maintain firewall rules, control backups… you get the picture. Understanding IAM allows you to ensure that these functions are assigned to the appropriate people. Your certified public cloud partner can evaluate your IAM access controls and recommend the best security model. 

• Cloud Quotas are allotted to each public cloud project and region. As you’re building systems, pay attention to the specific public cloud quotas to make sure that you aren’t about to hit your standard limits. Quotas can be extended quickly and easily if they are reasonable requests such as extending persistent disk SSD by 1 Tb. Just don’t expect to extend SSD storage by 1 Petabyte without doing some capacity planning with the public cloud vendor or your certified cloud partner. Quotas are important to stay on top of, if you don’t you might not be able to build those 10 systems you need to have done by tomorrow morning! 

• Get to know the Machine Types. SAP doesn’t support or recommend all of the available public cloud machine types, so you’ll have to choose the closest fit based on your SAP Quick Sizer or SAP HANA sizing output. You can also customize machine types so long as CPU to memory stays within the SAP recommended ratio. There is a benefit to knowing what machine types you plan to use for each of your server builds because it allows you to starting thinking about Committed Use Discounts, which I’ll cover later. 

• Capacity Planning and Compute Reservations are two different things, but are closely related. You might ask, why you’d need to think about capacity planning? I’m going to a public cloud platform so I can stop thinking about capacity planning, right? Well it is still beneficial to consider this as you are entering a large migration project. Ideally your certified public cloud partner would be working closely with the cloud vendor to let them know that they’re about to see 200 servers created on their infrastructure over the next three months. Even public cloud datacenters have a finite set of compute resources available. Letting them know how many servers you’ll be creating in a specific zone, with the machine types of those servers for the CPU, RAM and disk requirements will ensure that the public cloud has the compute available to support you as you provision your servers during each phase of the migration. Compute Reservations are similar to capacity planning in a way because they allow you “pin” public cloud resources to your project without them be used by other public cloud customers. One day you could run into a situation where your SAP Basis team needs to restart your SAP Production HANA server. If the particular region your server resides in is tight on resources, you could be forced to use a different instance type after the reboot. This could result in reduced performance. If you had reserved compute prior to the restart of your SAP HANA server, your stake on “ultramem” that specific instance type compute would have been protected it from other customers. Please note that you will start paying for compute that you reserve as soon as the reservation is created. 

• Database Backups aren’t rocket science in the public cloud. Typically, your database backup will either integrate with SAP BACKINT and will write the backup directly into a Cloud Storage Bucket or will be backed up to a local filesystem and then copied to a Cloud Storage Bucket. Either way, your backups will be stored in a Cloud Storage Bucket and the settings maintained for the Bucket will determine when data is copied to cold storage and how long it is ultimately retained in order to control storage costs. Because the Cloud Storage Buckets can be multi-regional, you’ll have the ability to restore your database backups to any public cloud VM around the world! 

• Disk snapshots are used to ensure that your VM’s disks can be restored. Think of disk snapshots as you existing OS backup or “foundation” to restoring a server. Before you can recover a database you first need your VM to be operational from a desired point in time. Disk snapshots give you the ability to restore one or more disks and the filesystems (Linux) or drives (Windows) that they back. Snapshots schedules can be created, and disks can be added to snapshot schedules as required. Plan snapshot schedules carefully because, like many other public cloud functions, they can’t be changed once created unless you delete them and start over. 

• You’ll find that the public cloud platform supports your traditional HA/DR needs. You can provision an HA Linux cluster to support your HANA environment or setup SAP HANA system replication to provide a DR option for a production server. Again, this is pretty basic stuff, but to achieve the best HA/DR configuration you need to provision servers appropriately and span them across multiple regions for the best outcome. Your certified public cloud partner is the best resource for configuring your environment in the best way possible. 

• Your Monitoring Solution should be as cutting edge as your new public cloud platform. Choose a certified public cloud partner that knows SAP Basis and implements automated monitoring tools. Learn more about how Protera uses Watchdog to automate SAP application, database, server and cloud monitoring here. 

• You have a shiny new toy and it comes at pretty penny unless you take advantage of cost saving options that the public cloud provides. Commits or Committed Use Discounts (CUD) provide an option to commit to using a specific amount of CPU, RAM instance types to achieve significant savings. As mentioned earlier, if you plan this out well enough, you can have the bulk of the public cloud landscape use machine types of one or two commitment types so that you can simplify your CUD purchases. It’s a little difficult to explain, but CUDs are both simple and tricky at the same time. If you over commit, you are locked into a 1 or 3-year agreement with the public cloud vendor to pay for the CUD compute you purchased and may not need. If you under commit the compute resources of VMs that you’ve provisioned won’t be subject to discounted rates. It’s best to err on the side of under committing because you can always purchase an additional CUD, just note that the 1 or 3 year commitment starts at the time of that new CUD’s purchase. CUDs and Sustained Usage Discounts are different. You need purchase CUDs whereas Sustained Usage Discounts are automatically applied if your VMs are running for the required amounts of time to qualify. Note: CUD cost savings are greater than Sustained Usage Discounts, so it pays to commit! 

• Track your Billing. The public cloud vendor provides a billing dashboard that you should closely monitor with your certified public cloud partner until you’ve built the vast majority of all VMs required to support your entire SAP migration. Use the billing dashboard to monitor the effect of Sustained Usage Discounts and CUDs and stay on top of your monthly spend to avoid sticker shock when you get you your first month’s and subsequent months’ bills. 

Bottom line: Don’t wait until the project starts to begin planning and executing some of key steps towards moving to the public cloud. 

Nobody likes a surprise migration, so plan early and plan often. 

 Contact our team to discuss your SAP migration.