India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP on Cloud: S/4HANA and HANA on AWS, Azure and Google Cloud
SAP on Cloud is the design, migration and operation of SAP ECC, S/4HANA, BW/4HANA and HANA databases on certified hyperscaler infrastructure instead of owned data-centre hardware. NTSPL sizes the landscape, builds HANA-certified platforms on AWS, Azure or Google Cloud, plans the cutover, adds HANA system replication for HA and DR, and runs the systems with SAP-aware monitoring and FinOps.
SAP on Cloud at a Glance
Most Indian SAP estates were built on hardware bought for an ECC 6.0 world: an Oracle or SQL Server database on a three-tier stack, a DR box that has never been failed over, and backups nobody has restored since go-live. Mainstream maintenance for SAP Business Suite 7 ends on 31 December 2027, the HANA appliance or Power server is due for refresh, and the board wants the move to S/4HANA done once, on infrastructure that will not need re-buying in five years.
NTSPL treats SAP as a workload with its own physics. HANA memory, log-volume latency, enqueue replication, Backint, transport routes and month-end batch windows decide the design, not generic VM templates. The twelve services in this family follow the order a CIO actually meets them: confirm technical readiness, choose the hyperscaler, design HANA and the S/4HANA platform, plan the conversion, protect it with HA, DR and backup, secure identities and network paths, and then run and cost-control the landscape week after week.
Four Workstreams That Take an SAP Landscape from ECC Hardware to Cloud Operations
Readiness, Placement and Migration Planning
Technical readiness of the current ECC or Suite on HANA landscape, an evidence-based choice of hyperscaler or RISE delivery partner, and a conversion plan with mock runs, downtime budget and cutover runbook. Outputs are sizing sheets, simplification-item lists, a scored platform decision and a dated migration calendar that avoids GST filing and quarter-close windows.
SAP Cloud Readiness Assessment
Technical SAP readiness check before cloud: HANA memory and SAPS sizing, OS and DB versions, Unicode status, add-ons, custom code and interface inventory.
SAP Migration Planning
Plan SAP moves to cloud: brownfield, greenfield or selective path, DMO or system copy, downtime budget, mock conversion schedule and hourly runbook.
Platform and HANA Engineering
HANA-certified compute and storage layouts, scale-up or scale-out decisions, ASCS/ERS and application-server design, private connectivity from plants and branches, and identity and encryption controls. Every build is written as Terraform or provider automation and validated with SAP's HANA hardware and cloud measurement tools before any data lands.
SAP S/4HANA Infrastructure
Build S/4HANA landscapes as code: certified HANA VMs, /hana volume layout, ASCS/ERS, app servers, Web Dispatcher and SAP OS images in Indian cloud regions.
SAP HANA Architecture
HANA design for cloud: scale-up vs scale-out, tenant layout, Native Storage Extension, memory headroom, Fast Restart and replication for S/4 and BW.
SAP Network & Connectivity
Connect plants, branches and partners to SAP on cloud: private links, SAP GUI and Fiori paths, RFC to MES, SAProuter, Cloud Connector and DNS.
SAP Security & Identity
Secure SAP on cloud: SSO for SAP GUI and Fiori, sidadm and root privileged access, HANA encryption keys, and SAP audit logs to SIEM for CERT-In.
Availability, Disaster Recovery and Backup
Pacemaker clusters with HANA system replication across zones, asynchronous replication to a second Indian region, Backint-integrated backups with immutable copies, and restore drills that prove point-in-time recovery. Each service is sized against a recovery tier agreed with finance and plant heads rather than a default template.
SAP High Availability
Zone-redundant SAP HA: Pacemaker clusters for HANA system replication and ASCS/ERS, fencing, virtual IPs and failover tests on AWS, Azure, GCP.
SAP Disaster Recovery
SAP DR on cloud: async HANA system replication to a second Indian region, app-tier recovery, DNS switch, DR drills and RPO/RTO evidence for S/4HANA and BW.
SAP Backup & Recovery
SAP HANA backups on cloud: Backint agents, 15-minute log backups, snapshots, immutable copies, catalog hygiene and monthly point-in-time restores.
Operations and SAP FinOps
Day-two operation of SAP Basis, HANA and the cloud layer: alerting on work processes, update errors, HANA memory and replication lag, patch cycles for kernel and HANA revisions, plus cost governance that covers memory-optimized reservations, non-production schedules and storage tiers per SAP system ID.
SAP Monitoring & Operations
Run SAP on cloud: HANA and Basis monitoring, alert runbooks, kernel and HANA patch cycles, job and transport operations and monthly SLA reports.
SAP Cloud FinOps
Cut SAP cloud cost: HANA reservations, non-production shutdown schedules, storage tiering, memory rightsizing, OS licensing and RISE vs IaaS views.
What an SAP Board Sponsor Can Hold Us To
How SAP Landscapes Are Built on AWS, Azure and Google Cloud
On AWS, NTSPL deploys SAP with AWS Launch Wizard for SAP on EC2 High Memory or R and X family instances, registers HANA with AWS Systems Manager for SAP, protects it with AWS Backup for SAP HANA and runs DR from Mumbai to Hyderabad, using overlay IP addresses for Pacemaker cluster failover.
On Azure, NTSPL builds SAP with Azure Center for SAP solutions on M-series and E-series VMs, uses Azure NetApp Files or Premium SSD v2 for HANA volumes, monitors through Azure Monitor for SAP solutions and replicates HANA from Central India in Pune to South India in Chennai for disaster recovery.
On Google Cloud, NTSPL runs SAP on M-series and X4 memory-optimized machines with Hyperdisk, installs the Google Cloud Agent for SAP for metrics and Backint backups, checks configuration with Workload Manager and replicates HANA between the Mumbai and Delhi regions for in-country DR.
SAP on Cloud in Practice: Industry Scenarios
Two-wheeler OEM cuts sized HANA memory from 6 TB to 3.4 TB before buying capacity
Specialty steel maker builds five S/4HANA tiers from code in 19 days
Aluminium extruder avoids a HANA instance upgrade by moving 1.1 TB to NSE
Power transmission EPC fits a 4.6 TB S/4HANA conversion into a 40-hour window
Edible oil refiner cuts SAP outage from a host fault to 4 minutes with zonal HSR
Pumps and valves maker brings S/4HANA up in Delhi in 1 hour 48 minutes
SAP on Cloud: Frequently Asked Questions
Does NTSPL run SAP under RISE with SAP or on our own cloud account?
Both models are supported, but the work differs. Under RISE with SAP, SAP runs the infrastructure and Basis layer, so NTSPL focuses on readiness, conversion, integration and the customer-side responsibilities. On your own AWS, Azure or Google Cloud account, NTSPL designs, builds and operates the full stack, including HANA, clusters, backup and cost.
Which SAP products can be moved with these services?
SAP ECC 6.0, Suite on HANA, S/4HANA, BW on HANA, BW/4HANA, SAP CRM, SRM, PI/PO, Solution Manager, GRC and the NetWeaver Java and ABAP stacks behind them. SaaS products such as SuccessFactors or Ariba stay with SAP, and NTSPL covers only their integration paths and identity.
How long does a full SAP move to cloud usually take?
A like-for-like move of an existing HANA landscape takes 10 to 16 weeks. A brownfield ECC to S/4HANA conversion with a database change usually takes 6 to 9 months, driven mostly by custom-code remediation, finance data checks and at least two mock conversions rather than by infrastructure build time.
Can SAP on cloud meet Indian data residency expectations?
Yes. Production, DR and backups can all be kept inside India by pairing AWS Mumbai with Hyderabad, Azure Central India with South India, or Google Cloud Mumbai with Delhi. NTSPL also routes SAP security audit logs to an Indian-region store to support CERT-In's 180-day log retention requirement.
Do we need to convert to S/4HANA before moving to cloud?
No. Many customers lift ECC to cloud first, sometimes migrating the database to HANA at the same time, and convert to S/4HANA later on cloud capacity. The right order depends on hardware expiry dates, custom-code volume and how much change the finance team can absorb in one year.
Who is accountable for SAP Basis after go-live?
That is agreed in a written RACI before cutover. NTSPL can run Basis and the cloud platform together under one SLA, or run only the infrastructure, HANA and backup layers while your Basis team or an SAP AMS partner keeps application support, transports and authorization changes.