This checklist will help you to improve the design, migration, implementation, and maintenance of your SAP systems on Google Cloud.
As you go through the checklist, take into account your own business needs. If you make choices that differ from what we've recommended, keep track of those differences for later tasks in the checklist.
Compute
- To verify if the machine types and software that you plan to use for your migration are certified by SAP, see SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types .
- Try to avoid running multiple applications on the same VM instance.
However, if you choose to run more than one application on a single VM:
- Make sure the applications don't compete with each other for resources and bandwidth. Otherwise, move the applications to separate VMs.
- We recommend using Cloud DNS to resolve the static IP addresses rather than using a local resolver.
Make sure you estimate sizing for your planned SAP workloads and allow for future growth.
- To evaluate your sizing options based on the implementation type, see Benchmark | Sizing (SAP) and Sizing (Google Cloud).
To reserve excess capacity based on growth requirements or failover needs, see Reserving Resources.
To optimize cost and efficiency, review the benefits of sustained use discounts and committed use discounts. These tools help you take advantage of the flexibility of cloud resources, and help you use only the resources that you need.
Networking
To design your Virtual Private Cloud (VPC) network for optimal performance, see the Best Practices VPC Design guide. We recommend the following design choices:
- Use the Premium network service tier. For information, see Network Service Tiers.
- Choose IP address ranges that do not conflict with each other, and include any existing on-premises IP address ranges into your planning and design.
- Decide on your network design and configuration before deploying
resources for the following reasons:
- You cannot add network interfaces or change the assigned cloud network once a VM is deployed.
- If you need to make changes, you'll need to redeploy instances. Such changes could impact the availability of your landscape and applications.
To learn about the benefits of a shared VPC, see the Shared VPC overview guide. In general:
- Shared VPC limits network administration access to the host project. This feature segregates network configuration access, which can be useful in delegated access scenarios. For example, you can allow developers to deploy VM instances in a test project, but prevent them from changing the network configuration.
- Shared VPC also imposes limits. For example, if Service Accounts in a service project need to make route updates in a high-availability (HA) scenario, you can use custom roles and conditions to restrict access to very specific resources.
- If you select Shared VPC for your landscape, create the Shared VPC before deploying VMs to your projects. This practice prevents you from having to redeploy instances and redo the network configuration if you choose to move to a Shared VPC at a later time.
To provide connectivity from your on-premises environment to your Google Cloud project, see Choosing a Network Connectivity product. We recommend the following:
- Do not create an external IP address for systems that do not require external access. This practice secures your system by limiting outside access.
- For internal communication, use firewall rules to limit access to the protocols and port numbers that your landscape actually uses.
- For access to your Google Cloud environment, see the Cloud NAT overview for details about outbound access and Using IAP for TCP forwarding for inbound, administrative access.
- If you are considering using third-party network appliances (such as proxies, firewalls, packet inspectors, load balancers, and web application firewalls), ensure that these services do not limit bandwidth or cause interruption to your VPC. Please work with your provider to ensure the solution is appropriate for SAP systems, and have them apply the necessary exclusions to limit impact.
Storage
- When you save backups to a persistent disk:
- Ensure that you offload the backup files to a secondary location for redundancy. You can accomplish this by creating a snapshot of this volume once the backup completes.
- Select a storage location that is redundant for the particular risk that you wish to mitigate (such as logical corruption, zonal outage, or regional outage). Using a second region as the secondary location is often a good choice.
- When upgrading any SAP components, consider the following:
- To change your backend database, review the SAP Database Migration Option (DMO) for Software Update Manager (SUM) guides for suggestions on how to combine an upgrade with the migration. See DMO of SUM 1.0 and DMO of SUM 2.0.
- To ensure an easier migration, review your current source system data. We recommend that you archive historical business data and delete temporary data before the migration. Doing so reduces your data footprint and the migration time.
- To implement a lift-and-shift migration, you can use a variety of tools based on your migration needs. Here are some examples of commonly used tools:
- For more information about migration strategies, see Migration to Google Cloud: Getting started.
- To define security requirements for workloads on Google Cloud,
see the
Cloud Security Best Practices
guide. We recommend the following:
- Always follow the least privilege principle, but make sure that team members have enough access privileges to allow them control and flexibility when carrying out their duties.
- Use anti-virus and anti-malware applications with care, especially with performance-sensitive applications (such as database servers).
- Apply appropriate restrictions on files to support your security posture (such as access to database storage).
To view the conditions required by SAP to provide support for your SAP on Google Cloud landscape, see SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisites .
Notably, this includes the requirement of installing the Google Cloud's Agent for SAP on your Compute Engine VMs or Bare Metal Solution servers, regardless of the SAP product that you run on them. For more information, see the documentation for your deployment scenario.
For more information about getting support from Google Cloud and SAP, see Getting support for SAP on Google Cloud.