The commoditization of technology has reached its pinnacle with the advent of the recent paradigm of Cloud Computing. Infosys Cloud Computing blog is a platform to exchange thoughts, ideas and opinions with Infosys experts on Cloud Computing

« Accelerated Cloud Environment Discovery | Main | Enable Enterprise self-service through AWS ASM connector for ServiceNow »

Infosys approach to SAP on Cloud assessment.


 Today, operational and business agility within organizations need to be improved to deal with the new challenges and seize opportunities. Cloud computing is proving to be the key to achieve these goals. This technology allows to meet the organizations requirements and to benefit from virtually unlimited resources. However, the migration of SAP to Cloud from the organization to a cloud environment is not trivial and requires considerable effort. The organization must follow a comprehensive process to ensure the migration of its information system. Exhaustive analysis and planning are required to ensure successful migration. Different public cloud CSP and cloud migration approaches are evaluated. This blogpost is based on a detailed analysis of the current SAP landscape and all its components. We propose a methodology on how to assess current state and propose options, in order to help organizations, make decisions during their journey towards SAP on cloud migration.

Context : 

A lot of SAP customers are evaluating public cloud for infrastructure as a service. This is driven by various reasons including TCO reduction, agility and scalability. This blogpost uses one such real-world experience for a customer to lay out the approach to SAP on Cloud assessments, the best practices and watch-outs while performing such an exercise.

The customer's existing infrastructure hosting the SAP applications is niche and expensive. The multiple SAP business initiatives underway require that the platform be upgraded, scaled for capacity and additional environments added to meet parallel projects and testing. All this led to the customer looking for a more cost effective, at the same time, scalable and agile platform to modernize their SAP infrastructure platform to provide business the technological flexibility and agility.

The assessment exercise comprised of understanding the current SAP infrastructure setup and its limitations, architect a target state solution that fits requirements, compare solution and price across two leading cloud providers and come up with a final recommendation

Problem Statement - the Business Case for SAP on Cloud 

The SAP application is hosted on a legacy proprietary platform. This led to challenges with respect to application performance, architectural challenges for management, restricted scalability and database constraints to scale. The SAP Landscape was heterogeneous in nature and expected to grow exponentially (~300%) in the next 2-3 years due to business transformation programs. The current platform cannot scale to this demand without incurring huge expenditure to perform a costly hardware refresh.

This led to the search for alternate hosting solutions which can scale seamlessly with demand and at a linear and predictable cost. Public cloud fit the bill perfectly and brings the following additional benefits:

  • Reduced TCO by moving to innovative pricing models offered by Hyperscalers
  • Drive infrastructure cost optimization with different architecture deployments, warm or cold DR at a fraction of cost and right sizing of the environment with ability to scale-up or scale-down as per demand
  • Automation of routine tasks such as Installations and System Refresh using templates and scripts leading to efficient operations.

An assessment was performed covering, study of the current state infrastructure, develop a target state design on multiple Hyperscalers to compare costs and recommend a migration roadmap to achieve the stated objective.

Solution Options

The target solution/platform has various possible options right from the infrastructure platform (on premise vs cloud) to the choice of the Operating system and database combinations. The options had to be evaluated for the SAP application compatibility and compatibility with the chosen infrastructure platform. It is also advisable to align the options made to the SAP product roadmap for its applications.

The below table provides a matrix of probable options that were evaluated. 

sap 1.pngBased on the considerations mentioned, we narrowed the potential target options to 3:

    • SAP on Linux/Sybase on AWS
    • SAP on Windows/MSSQL on Azure
    • SAP on IBM P Series running Linux/DB2 on premise

Deeper analysis was restricted to the public cloud options (options 1 and 2) mentioned above.

Detailed assessment


This section considers the detailed assessment conducted as part of this exercise as well as the target state designed with multiple options for cost comparison.

a.      Inputs for the exercise

In the initial discovery phase, data on the current SAP infrastructure was collected on the following broad aspects:

  •        The SAP information was collected from latest SAP Early Watch Alert reports.
  •        The physical infrastructure details were collected from inventory excel sheets maintained by the infrastructure teams.

Challenge: The data gathering on infrastructure from the incumbent vendor took a long time and multiple meetings as most of the data was in multiple excel spreadsheets and not up to date. The utilization metrics were not comprehensive & accurate. The data was reconciled with the EWA reports and gaps addressed.

Best Practice recommendation:

    •      A tool-based approach for infrastructure discovery
    •      Agree with the customer that all data collection configuration setup - both infrastructure level and SAP EWA reports for all environments.
The detailed information collected from the discovery exercise which fed into the analysis and design phase were:

    •        SAP Applications with versions, the NetWeaver stack version and kernel patch levels
    •        Operating system and Database with versions
    •        Database sizes
    •        Number of environments for each of the SAP applications
    •        Physical architecture details covering datacenters, compute and storage
    •        Hardware information for the applications - Compute (Make & model) with CPU and memory, storage and network
    •        Logical architecture deployment of the SAP systems with HA and DR
    •        Current utilization of compute (from SAP EWA reports) and storage.
    •        Integrated ecosystem of applications - this will help analyze impact on surrounding applications when SAP moves to the cloud
    •        Other strategic initiatives/projects planned in the next year impacting the SAP systems in scope

Other topics that were discussed which had an impact on the target state were:

    •        The current OS version is out of date and the underlying storage has performance issues
    •        There is no regional DR available and the current solution has HA and DR as the same solution
    •        The database layer had physical limits for scalability and was limiting growth
    •       There were other improvement initiatives planned - SAP PO migration to Linux and large functional rollouts planned which will increase the database size exponentially

b.      Key considerations for SAP on Cloud assessment


  •             Maximize current investment on ECC 6.0 as there are no plans for S/4 HANA for next 4-5 years.
  •                  Evaluate investment left in current hardware along with buyback/reuse possibilities across hardware, OS and DB licenses
  •            The CSP and platform (OS and DB combination) chosen should be widely in use by large SAP retail customers with high SAPS
requirements and very large database sizes.
  •            Support for exponential growth - database growth, compute expansion
  •           The target solution designed should be Future proofed with SAP roadmap for SAP application versions and OS/DB combinations. At the time of this assessment, the key constraint was ECC not supported beyond 2025 had to be considered.

c      Target Solution

Through structured meetings with key stakeholders, collect target state requirements in the standard Non-Functional Requirements (NFR) template. The key data captured were:

  •          Target regions on the cloud
  •           High Availability
  •           DR requirements (RPO, RTO)
  •          Network connectivity and security
  •          Monitoring and logging
  •          Backup & Restore requirements

Target architecture

Based on the data collected and analyzed in the discovery phase and the target state requirements, the target architecture for the cloud could be -a like-to-like scenario mirroring what is available on premise or the other meeting all the NFR that were gathered for target state.

The key tenets for target architecture design were the following:

  •         Design - Open architecture and Ease of portability between infrastructure platform
  •         Technology platform - Scalability, Sustainability, Performance and Highly Available
  •         Process - Governance, Environment rationalization, Software standardization and use of Best Practices

Based on the above principles, the key design considerations agreed with the customer were:

Design topic


Central vs Distributed architecture

Distributed - each SAP component has its own VM

Multiple SAP applications in one LPAR/VM/host

Restrict one application to one VM

Number of non-production environments

BAU - Dev, QA, Pre-Prod

Project - Dev, QA

Architecture and sizing for Pre-prod

Same architecture as Prod

Sizing can be lower (impacts performance testing)

DR architecture

Same as prod (impacts RTO)

Load balancing for app servers

3 app servers for Prod sized to 120% load (80% available in case of a failure)


Reference physical and logical architectures with full HA and DR capabilities:

sap 25.png

sap 35.png

Target sizing


Multiple SAP SIDs were installed on one LPAR and in some cases, multiple components of the SAP system (Central services, Database) were installed on the same LPAR. Hence, the actual values for sizing the target (SAPS & Memory values per application and component) were not readily available and needed to be derived using best practices and formulae.

For sizing the SAP environment on cloud, we considered the following design principles:

  •          Distributed architecture with Central Services, Database and Application servers on individual VMs
  •         Wherever database and application were on the same LPAR, the SAPS for target VMs was split as 40% for database and 60% for application
  •         For the database VMs, the SAPS derived from calculations were used as 65% sizing levels in the target.
  •         Storage for SAP application servers were taken as 150GB

For target sizing on the cloud, additional SAPS & memory was considered as 10% and database storage as 20% 

d      Technology comparison

Choices considered across Operating System, Database and Cloud Providers to arrive at the target SAP platform.

Operating System

Selection criteria:

  •        Widely used among large SAP customers
  •        Integrated support for HA, DR and monitoring
  •        Ease of use and administration
  •        Partnerships and innovations with SAP





License costs


$$ **


Highly secure

Perceived as less secure

(hacks/virus attacks)

System administration

Requires involvement


Support for HANA (future roadmap)



Knowledge/skill of existing IT staff

High (RHEL)


Alignment to the strategic IT roadmap



HA and DR for SAP



Replication and fail-over technology to automate the takeover process.

RHEL/SUSE for SAP comes with HA and Smart Management enhancements tailored to SAP

Microsoft (MSCS) offers a standard high availability solution for SAP



Selection criteria:

  •        Widely used among large SAP customers
  •        Scalable, high performant and supports very large databases
  •        Aligns to long term application product roadmap



Sybase ASE


DB2 for LUW

Total Cost of Ownership

licenses, deployment, management and storage compression




Single vendor for stack

Yes (with App)

Yes (with OS)


SAP roadmap/support

Long term



Subscription offerings on Cloud

License bundled


On Azure & AWS


Integrated development cycles

Reduces the risk of software updates and testing duration

Aligned with SAP releases



Skill availability in market

DBA availability, trainings, guides




Ease of maintenance

Zero/Self-management, easy tuning





For HA and DR

Always On

Always On



* Support is not from SAP but community support

Cloud Provider




Auto recovery for VM failures

Up to 1 hour (EC2 instance recovery)

SLA in Availability zones is 99.99%

15-30 mins (Service Healing)

SLA in Availability sets is 99.95%

Storage sizing

Flexibility in choosing any size for both gp and io2

Choose from predefined sizes for both Standard and Premium Managed (SSD) Disks

Reserved instances

Available with option of full, partial and no upfront payments for both 3 and 1 year

Available with only upfront payments for both 3 and 1 year

Data transfer options

AWS Data Sync



Fast Data Transfer (Microsoft Garage Project)

Shared storage

EFS (AWS native service)

NetApp (3rd party)

Sybase Support

SAP ASE or higher

SAP ASE 16.0 SP02 or higher

Linux support

SUSE Linux Enterprise Server (SLES) 11 or higher

Red Hat Enterprise Linux (RHEL) 7 or higher

SUSE Linux Enterprise Server (SLES) 12 and higher

Red Hat Enterprise Linux 7 (RHEL7) and higher

Largest SAPS

Virtual - 135,230 (m5.24xlarge)

Dedicated - 480,600 (u series)

Virtual - 259,950 (Standard_M208s_v2)

Dedicated - None (for ECC on Any DB)


Cloud Endure (starting from $70, volume discounts apply)

Azure Site Recovery

($25 per VM, no volume discount)

Scale-out support for BW

R Series (244 & 768GB), X1 Series (1, 2 & 4TB)

M128s (2TB)

* This information is accurate at the time of the assessment exercise - Q3-2019

e      TCO calculations

The cloud services and components that were priced to arrive at the TCO were:

1.       Compute (SAP certified instance types) including OS licenses

2.       Storage - Block storage for Compute, Object storage for backups and archives and Network file shares

3.       Network connectivity, Load balancers and Data out charges

4.       Native tools for Backup and Monitoring services

5.       Database licenses for SAP ASE

6.       Ongoing operations support for Infrastructure

With the initial pricing determined for the Bill of Material using standard pricing calculator from cloud service providers, multiple optimization levers were applied to fine tune the cost of infrastructure on the cloud to get the most optimum pricing. The various levers that were used were:

1.       3 years' reserved instance pricing - identified applications that will be continuously used and marked them for PI. Others were marked as On-demand with operational number of hours/week agreed (typically 8x5 or lesser)

2.       Rationalization of environments - some applications had a lot of non-production instances. The baseline environments were agreed, and others were marked as on-demand for build-use-destroy

3.       Software license negotiations for SAP ASE, MSSQL Server

4.       Optimal choice of storage options based on environment, throughput needed for performance and business criticality of the application.

5.       Ideal network connection sizing based on bandwidth estimates

6.       Optimization of migration costs 

f      Final recommendations report

A final recommendation presented to  the key stakeholders included the following:

  •        TCO report consisting of infrastructure cost estimate on the cloud, software license fees, one-time migration cost and ongoing operations support costs
  •         A high-level migration roadmap to achieve quick wins and risk mitigated migrations for the business-critical systems

sap 41.png

  •          A week-by-week migration plan with SAP system grouped into migration waves
  •        A set of technical/architectural recommendations that can be performed on premise to increase resiliency in the SAP systems, standardize platforms, reduce the systems and data footprint to help set the stage for a future cloud migration.

Infosys Service Offering

Infosys typically performs such SAP on Cloud assessments based on a 6-week detailed plan. The duration of the exercise and the outcomes will be tailored based on customer SAP estate and target requirements.  At the end of the exercise, customers would get a target bill of materials, TCO for the chosen option(s) and a high-level migration roadmap.

sap 51.png

About the Authors:

  • Madhuchandra Puttappa is a Public Cloud Architect specialized in SAP on AWS 
  • Sivaramakrishnan R is a SAP Basis Architect focused on SAP on Cloud migrations.


Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.