India’s Leading Domain & Web Hosting Provider
Support
Domain & Login
Blog
SAP on Google Cloud: S/4HANA Migration, HA/DR and BigQuery Analytics
SAP on Google Cloud is the practice of running SAP S/4HANA, ECC and BW landscapes on SAP-certified Compute Engine machines such as the M3 and X4 series, with Hyperdisk storage and Google Cloud's Agent for SAP for monitoring and Backint backups. NTSPL plans, migrates and operates these landscapes for Indian retailers and manufacturers, including HANA high availability, Mumbai-Delhi DR and BigQuery analytics on SAP data.
Google Cloud services in scope
The Problem Compute Engine memory-optimized M3, M4 and X4 machine series and Hyperdisk Extreme and Hyperdisk Balanced Solve
SAP landscapes punish generic cloud designs. HANA needs memory-to-vCPU ratios and storage throughput that only certified machine types and disk configurations guarantee; a HANA database on an uncertified VM is unsupported by SAP, whatever its benchmark. Failover must keep HANA System Replication, the Pacemaker cluster and the virtual IP consistent, or a zonal event becomes a split-brain at month-end. Backups of a multi-terabyte database must complete inside the window and restore within the agreed RTO. And business users still want SAP data next to e-commerce and distributor data, which ABAP reports cannot deliver. The problem is getting sizing, availability, backup and data extraction right for SAP specifically.
NTSPL starts from SAP's own artefacts: the EarlyWatch Alert, the HANA sizing report and the custom code analysis. We map each system to a certified machine type, choose Hyperdisk configurations against SAP's storage KPIs, and build HANA HA with a Pacemaker cluster across two Mumbai zones and asynchronous replication to Delhi. Google Cloud's Agent for SAP is installed on every host for metrics and Backint, Workload Manager checks the deployment against SAP best practices, and SAP data flows to BigQuery through replication rather than nightly flat files.
When to Move SAP to Google Cloud, and Which Landscapes Should Wait
Signals that point to sap on google cloud on Google Cloud
- SAP ECC must move to S/4HANA before the end of SAP's mainstream maintenance, and your on-prem HANA appliances are due for refresh.
- Month-end close or MRP runs exceed their windows because the current hardware or storage is saturated.
- Your DR site is a cold copy restored from tape or daily backups, and the auditors' RTO expectation is hours, not days.
- Analytics teams extract SAP data through nightly flat files or BW and wait a day for numbers.
- Non-production systems run 24x7 on owned hardware but are used only during working hours.
- You are evaluating RISE with SAP and want an independent view of the infrastructure and operations model on Google Cloud.
When a different approach is better
- If you have already signed RISE with SAP, SAP operates the infrastructure; NTSPL's role then shifts to integration, BigQuery analytics and non-SAP workloads, not landscape design.
- If the landscape is small SAP Business One with a few dozen users, a certified HANA cluster is excessive; a single appropriately sized VM or SAP's own hosted option is simpler.
- If the plan is to replace SAP within two years, a lift-and-shift to Google Cloud rarely pays back; extend on-prem support and invest in the target system.
SAP on Google Cloud Building Blocks: Certified M3 and X4 Machines, Hyperdisk, Agent for SAP and Workload Manager
| Service | Role in the architecture | Choose it when |
|---|---|---|
| Compute Engine memory-optimized M3, M4 and X4 machine series | Provide SAP-certified machine types for SAP HANA, from hundreds of GB of memory on M3 and M4 to multi-terabyte X4 bare-metal instances for the largest scale-up databases. | The HANA sizing report requires more memory than general-purpose machines provide, or SAP support requires a certified configuration. |
| Hyperdisk Extreme and Hyperdisk Balanced | Block storage with independently provisioned IOPS and throughput, used for HANA data and log volumes to meet SAP's storage performance KPIs. | HANA savepoints, log writes or startup load times are limited by disk throughput, or you need to tune performance without resizing capacity. |
| Google Cloud's Agent for SAP | Host agent that collects SAP and HANA metrics into Cloud Monitoring, supports Workload Manager evaluations and includes a Backint feature that backs up HANA directly to Cloud Storage. | Every SAP host on Google Cloud; it is the basis for support, monitoring and native HANA backups. |
| Backup and DR Service for SAP HANA | Captures application-consistent HANA backups through the backup/recovery appliance with incremental-forever capture and fast mount-based recovery and cloning. | Large HANA databases need faster restores or system copies than file-based Backint backups allow, or backups must sit in an isolated vault. |
| Workload Manager | Evaluates SAP deployments against Google Cloud and SAP best-practice rules, such as OS settings, Pacemaker configuration and disk layout, and reports deviations. | You need continuous evidence that the landscape still matches the certified, supported design after changes. |
| BigQuery Connector for SAP and Cortex Framework | The connector replicates SAP tables into BigQuery through SAP Landscape Transformation Replication Server; Cortex Framework supplies reference data models and Looker content for SAP finance, sales and supply chain data. | Business users need SAP data joined with non-SAP sources in near real time without building BW extractors. |
SAP S/4HANA with HANA System Replication across Mumbai zones and DR in Delhi
SAP S/4HANA with HANA System Replication across Mumbai zones and DR in Delhi
SAP GUI and Fiori users reach the application servers through Cloud Interconnect or Cloud VPN, with Fiori exposed through an internal load balancer and SAP Web Dispatcher. The ABAP SAP Central Services and HANA layers run in Pacemaker clusters across two asia-south1 zones with synchronous HANA System Replication, asynchronous replication feeds a DR node in asia-south2, and SLT replicates selected tables to BigQuery.
Select any component
SAP S/4HANA with HANA System Replication across Mumbai zones and DR in Delhi: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 7-step primary path.
SAP Landscape Decisions: HANA Sizing, Storage Layout, Pacemaker HA, Mumbai-Delhi DR and Migration Path
HANA sizing and machine selection
We size from the HANA sizing report and current memory usage plus data growth for three years, not from the on-prem appliance size, which is usually over-provisioned. Databases up to a few terabytes typically fit M3 or M4 machine types; X4 bare metal is for the largest scale-up systems. We size after archiving and data aging decisions, because removing two years of change documents can drop a machine tier. Application servers use certified general-purpose types, sized by SAPS from the EarlyWatch Alert.
Storage layout and Hyperdisk performance
HANA data and log volumes get separate Hyperdisk volumes so log write latency is not affected by savepoints. We provision throughput and IOPS to meet SAP's HCMT storage KPIs and validate with HCMT before go-live rather than trusting defaults. Hyperdisk lets us raise throughput for month-end or migration loads and lower it later without resizing. Shared and backup volumes use cheaper Hyperdisk Balanced or Cloud Storage, since Backint removes the need for a large local backup disk.
High availability across zones
Production HANA and ASCS each run in a two-node Pacemaker cluster across two Mumbai zones, using the SUSE or Red Hat high-availability add-ons with Google Cloud fence and load balancer resource agents. HANA System Replication runs synchronous in-memory with table preload on the secondary so takeover completes in minutes. We test takeover, fencing and failback under load before go-live, and Workload Manager checks the cluster configuration weekly so drift does not break failover.
Disaster recovery to Delhi
For Tier 1 SAP, we add asynchronous HANA System Replication to a third node in asia-south2, giving RPO in minutes and RTO of one to four hours including application server start. To control cost, the DR node can run a smaller instance with replication loaded into memory partially, or host a QA system that is shut down at invocation. For lower tiers, Backint backups copied to a Delhi bucket provide DR with longer RTO. DNS and interface endpoints are scripted for failover.
Migration path: lift-and-shift, conversion or new implementation
For ECC on anyDB, we usually combine the move with an S/4HANA system conversion using SUM with Database Migration Option, landing directly on Google Cloud. Where the business wants process redesign, a new implementation or selective data transition is planned. For systems already on HANA, HANA System Replication to Google Cloud gives a near-zero-downtime cutover. Downtime is planned around plant shutdowns or low-sales windows, with at least two full rehearsals measured against the cutover window.
How NTSPL Migrates an SAP Landscape to Google Cloud Wave by Wave
SAP landscape assessment
Review EarlyWatch Alerts, HANA sizing reports, custom code analysis and interfaces to define target sizes, migration path and downtime windows.
SAP landing zone build
Create SAP projects and VPC in asia-south1 and asia-south2, Cloud Interconnect, OS images, Agent for SAP and Organization Policy guardrails.
Non-production migration
Move sandbox, development and QA first, validate HCMT storage KPIs and run Workload Manager evaluations.
HA/DR build and failover tests
Configure Pacemaker clusters and HANA System Replication, then test takeover, fencing, failback and Delhi DR invocation.
Production rehearsals and cutover
Run at least two timed rehearsals of the production migration, then cut over in the agreed window with go or no-go checkpoints.
Hypercare and analytics
Monitor through Agent for SAP metrics during the first month-end close, then enable SLT replication into BigQuery.
What you receive
Hardening SAP Landscapes on Google Cloud: Network Segmentation, OS Hardening and Privileged Basis Access
SAP holds a company's financials, payroll and supply chain, and its threat cases are specific: exposed SAP router or Fiori endpoints, shared SAP* or DDIC credentials, Basis administrators with standing root access, and unencrypted RFC traffic to third-party systems. On Google Cloud we segment the SAP VPC from other workloads, remove public IPs, control OS access through OS Login with IAM and keep SAP application security, such as roles and SNC, under the customer's SAP security team.
- No public IPs on SAP hosts; administrative access through Identity-Aware Proxy TCP forwarding
- OS Login with two-step verification and time-bound elevation for Basis administrators
- Firewall policies restricting RFC, SAP GUI and HANA SQL ports to named source ranges
- CMEK on Hyperdisk and Backint buckets for financial and payroll data
- Workload Manager rules to detect OS and cluster configuration drift
SAP on Google Cloud Cost Model: Memory-Optimized Commitments, Hyperdisk Throughput and Non-Production Scheduling
SAP cost on Google Cloud is dominated by memory-optimized instances for HANA, which run 24x7 in production and suit committed use discounts, and by Hyperdisk capacity plus provisioned throughput. Application servers, the DR node and non-production systems are where flexibility saves money. OS licences for SUSE or Red Hat for SAP are billed per instance, and Backint storage in Cloud Storage is far cheaper than local backup disks.
- Three-year committed use discounts on production HANA and ASCS instances
- Scheduled shutdown of development, QA and sandbox outside working hours
- Smaller DR node or co-located QA on the DR host until invocation
- Hyperdisk throughput raised only for migration and month-end, then reduced
- Data archiving and aging before sizing to drop a HANA machine tier
RISE with SAP on Google Cloud vs self-managed SAP on Google Cloud: which model should we choose?
Compare on four points. Scope of responsibility: RISE bundles the S/4HANA subscription, infrastructure and technical operations under one SAP contract; self-managed means you or a partner like NTSPL run Basis, HA and backups on your own Google Cloud projects. Control: self-managed gives direct access to the infrastructure, sizing, maintenance windows and integration with other Google Cloud workloads; RISE limits that to SAP's service catalogue. Commercials: RISE is a subscription; self-managed lets you apply existing SAP licences and Google Cloud commitments. Analytics and integration: both can feed BigQuery, but self-managed allows SLT and Agent for SAP configuration on your terms. Choose RISE for simplicity and a single contract; choose self-managed for control and cost transparency.
Key facts about sap on google cloud on Google Cloud
SAP on Google Cloud on Google Cloud in Practice
3 sap on google cloud scenarios from Retail, apparel and lifestyle, Food and beverages manufacturing, Chemicals, decorative and industrial paints: the starting position, the services chosen, the architecture, the rollout and the measured outcome.
Retail chain moves SAP S/4HANA retail landscape to Google Cloud before peak season
Beverages manufacturer gets same-day secondary sales visibility from SAP in BigQuery
Paints manufacturer gets 4-minute HANA failover and in-country DR on Google Cloud
SAP on Google Cloud on Google Cloud: Frequently Asked Questions
What does SAP on Google Cloud cost compared with on-prem HANA appliances?
For a typical mid-size S/4HANA landscape with a 2 to 4 TB production database, HA, DR and three non-production systems, Google Cloud infrastructure usually costs INR 12 to 30 lakh per month depending on commitments and DR design. That replaces appliance refresh, data centre, storage and backup costs. NTSPL builds the comparison from your actual sizing and includes three-year committed use discounts and non-production scheduling.
Can we move SAP ECC to Google Cloud and convert to S/4HANA at the same time?
Yes. SUM with Database Migration Option can migrate ECC from Oracle, SQL Server or DB2 to HANA on Google Cloud and, combined with a system conversion, land on S/4HANA in one programme. NTSPL usually rehearses twice, measuring each phase, to fit the cutover in a weekend or plant shutdown. Some customers move ECC first and convert later to separate infrastructure and functional risk.
Can SAP production and DR both stay in India?
Yes. Production runs in asia-south1 Mumbai across two zones for high availability, and DR runs in asia-south2 Delhi, so financial and personal data never leaves India. This satisfies most data localisation expectations under RBI rules for regulated entities and DPDP Act obligations. Organization Policy pins SAP projects to the two India regions to prevent accidental resources elsewhere.
How do HANA backups work on Google Cloud?
Most landscapes use the Backint feature of Google Cloud's Agent for SAP, which writes HANA data and log backups directly to Cloud Storage, certified by SAP and managed from HANA Studio or Cockpit. For very large databases or frequent system copies, Backup and DR Service gives faster mount-based recovery. NTSPL measures restore time for each system and chooses accordingly.
How quickly does HANA fail over between zones?
With a Pacemaker cluster and synchronous HANA System Replication with table preload, takeover to the second Mumbai zone typically completes in a few minutes, and application servers reconnect through the virtual IP. NTSPL tests takeover under load before go-live and repeats tests after OS or HANA upgrades, recording timings for audit and business continuity records.
How do we get SAP data into BigQuery?
The common path is the BigQuery Connector for SAP running in SAP Landscape Transformation Replication Server, replicating selected tables in near real time. Cortex Framework adds reference data models and Looker dashboards for finance, sales and supply chain. Alternatively, SAP Datasphere replication flows can target BigQuery. NTSPL chooses based on your existing SAP licences and latency needs.