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 migration. This blog post will explore answers to all of these questions and more to ensure your SAP migration to the cloud is smooth. Note, in this narrative I will mainly focus on the Google Cloud Platform (GCP) as the preferred cloud destination.
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 applications into the Google Cloud Platform? 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 Google Cloud partner like Managecore.
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 applications into the Google Cloud Platform? Managecore's expertise offers a unique pairing of GCP 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 GCP? 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 GCP.
- 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 data center. GCP supports importing systems from on-prem VMWare, Amazon EC2 and Microsoft Azure. Consider this as close to a true "Lift and shift" approach as will be possible when moving to GCP.
- DB replication – If SAP and GCP support your current database, you could use your database's native system replication methods to get your data into GCP 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 GCP environment.
- SAP tools – If your SAP version, OS or DB aren't supported on GCP or you are planning to upgrade SAP and change your OS or DB then you and your 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 GCP 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 of SAP instances. SAP tools only account for SAP standard filesystems and customers are responsible for their own directories. If the migration to GCP 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, integrations which are all things that an experienced Managecore SAP Basis project team 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 data centers. 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 GCP and one in the original data center or you'll shut down your original development server and only have the new system in GCP. In either case you have hurdles to overcome with how changes to 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 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 GCP 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 Google Cloud Storage Bucket?
- You can't just drive a NAS device up to a Google data center and ask their "smart hands" to plug it into your environment. The physical vessel for your data into a Google data center is limited to a Google Transfer Appliance. Using this option requires additional cost consideration, understating of timings and orchestration of human data center 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 GCP.
- 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 Google Cloud Platform
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 into the Google Cloud Platform, so what are some key considerations specific to GCP? Here is a taste of common challenges:
- Network Connectivity between Google Cloud Platform and customer sites such as data centers, corporate offices, branch offices, field locations, warehouses, etc. If your existing on-prem systems or systems at you hosting provider have access to a location this means that your systems in GCP will also need to have access to these same locations. If you have low tolerance for downtime during your migration then your best bet is to ensure that you have either a fast connection to GCP from your existing data center or you have a fast Internet upload speed from your existing data center. If you are currently in a hosting provider's data center, you'll also need to make sure that the network connectivity between your on-premises networks are ready for GCP 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 Google. 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 Google Partner can help ensure that you are securing your systems through your GCP firewall rules.
- Security (Identity and Access Management) in Google Cloud Platform can be complex. No this is not SAP level application server, that doesn't change from what you're used to. GCP, like 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 Google Partner can evaluate your IAM access controls and recommend the best security model.
- Cloud Quotas are allotted to each GCP project and region. As you're building systems, pay attention to the GCP specific 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 Google or your Google 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 Google's available 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 Google 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 Google Partner would be working closely with Google to let them know that they're about to see 200 servers created on their infrastructure over the next three months. Even Google's datacenters have a finite set of compute resources available in their public cloud. Letting them know how many servers you'll be creating in a specific zone, with the machine types of those servers and the CPU, RAM and disk requirements will ensure that GCP 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" Google resources to your project without them be used by other GCP customers. One day you could run into a situation where your SAP Basis team needs to restart your SAP Production HANA server. If that server is a m1-ultramem-160 machine type and the backend infrastructure supporting the "ultramem" class of compute within your VM's zone are exhausted, you may not be able to restart your VM without first switching to a "megamem" line of compute. This could result in reduced performance. If you had reserved compute prior to the restart of your SAP HANA server, your stake on "ultramem" compute would have been protected 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 GCP. Typically, your database backup will either integrate with SAP BACKINT and will write the backup directly into a GCP Storage Bucket or will be backed up to a local filesystem and then copied to a GCP Storage Bucket. Either way, your backups will be stored in a GCP 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 GCP Storage Buckets can be multi-regional, you'll have the ability to restore your database backups to any GCP 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 GCP functions, they can't be changed once created unless you delete them and start over.
- You'll find that Google 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 Google 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 Google Cloud Platform. Choose a Google Partner that knows SAP Basis and implements automated monitoring tools. Learn more about how Managecore uses Watchdog to automate SAP application, database, server and GCP Stackdriver monitoring here.
- You have a shiny new toy and it comes at pretty penny unless you take advantage of cost saving options that Google provides. Committed Use Discounts (CUD) provide an option to commit to using a specific amount of CPU and RAM associated with N1, N2, Memory Optimized or Compute Optimized commitment types to achieve significant savings. As mentioned earlier, if you plan this out well enough, you can have the bulk of GCP 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 Google 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. GCP provides a billing dashboard that you should closely monitor with your Google 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 Google Cloud Platform.
Nobody likes a surprise migration, so plan early and plan often! Don't underestimate the complexity of your migration or the required GCP expertise needed to be successful.
>>> Reach out to the SAP and cloud certified Managecore team to learn more about how we can help with you migrate your complete SAP landscape to GCP and ensure end to end project success.
Senior SAP Basis Consultant
As a senior basis consultant for Managecore's delivery team Jake carries out daily technical activities and end to end project support for our customers' full SAP landscape. Jake has over 14 years of professional SAP basis experience in both technical and leadership roles, where he has supported more than 50 SAP customers. With the wealth of technical knowledge he has acquired over the many years, his co-workers look to him as an SAP 'guru'. Today Jake's focus is on implementing SAP best practices for optimal basis support, SAP projects, cloud migrations and HANA upgrade projects.