SAP Cloud Migration: Infrastructure Requirements and Domain Configuration Essentials

Migrating SAP to the cloud is one of the most technically demanding projects an enterprise IT team can take on, and the gap between “we’ve decided to move” and “we’re live in the cloud” is filled with infrastructure decisions and domain configuration details that most guides simply skip over. This resource changes that. Whether you’re planning your first SAP cloud migration or trying to rescue a stalled project, you’ll find the technical specifics, honest risk assessments, and actionable steps you need to move forward with confidence.

Why SAP Cloud Migration Is No Longer Optional

SAP’s end-of-mainstream maintenance for ECC is the forcing function that’s pushing every enterprise IT roadmap conversation toward cloud. The deadline is real, the business pressure is mounting, and the window for a controlled, well-planned migration is narrowing every quarter you wait. Yet despite the urgency, adoption remains surprisingly low.

According to SAP User Group research, just 6% of respondents use S/4HANA in the private cloud and only 2% use S/4HANA in the public cloud. That gap between intent and deployment tells you something important: organizations know they need to move, but the complexity of an SAP S/4HANA transition is stopping them cold.

What’s causing the hesitation? Most teams underestimate two things. First, the infrastructure readiness work that has to happen before a single byte of production data moves. Second, the domain configuration changes that ripple across every SAP integration, web service, and user-facing endpoint when you shift workloads off-premises. These aren’t afterthoughts. They’re the difference between a migration that goes live on schedule and one that drags on for months past cutover while your team scrambles to fix broken RFC connections and unresolved hostnames.

This guide addresses both workstreams in depth, because no other resource currently does.

Infrastructure Readiness: What “Ready” Actually Means

Most migration guides treat infrastructure readiness as a checkbox. It isn’t. Infrastructure readiness for SAP HANA in a cloud environment means meeting specific, measurable thresholds that SAP certifies against — and failing to meet them doesn’t just slow your system down, it makes production workloads unreliable in ways that are difficult to diagnose and expensive to fix after go-live.

Compute Sizing

The compute requirements for SAP HANA are memory-first. Unlike traditional relational databases that persist data primarily to disk, SAP HANA stores and processes the bulk of its active dataset in RAM. This means your cloud VM instance size is determined not by CPU headroom but by the size of your HANA database — typically calculated as 1x to 1.5x your compressed in-memory dataset.

Cloud providers offer SAP-certified instance types specifically for HANA workloads. On AWS, this means the x1, x1e, or u-series memory-optimized instances. On Azure, the M-series and Mv2-series. On GCP, memory-optimized instances in the M2 family. Using non-certified instance types for production SAP HANA voids SAP’s support SLA and creates an untraceable liability — this is non-negotiable in enterprise deployments.

The performance improvement from migrating to a properly sized cloud environment can be dramatic. A technical benchmark across 157 enterprise implementations documented average query performance improvements of 1,800x for complex analytics operations and 15 to 20x acceleration for standard transactional processing compared to legacy disk-based systems.

Implementations also document an average reduction of 2,137 tables per project, along with a 73% reduction in average database size — meaning your cloud storage footprint will likely be smaller than your on-premises environment suggests, but your memory requirements per active record will be higher.

Storage: The IOPS Floor

Production SAP HANA workloads have a hard performance floor: a minimum of 10,000 IOPS for production environments, with enterprise-scale deployments frequently requiring significantly more. This figure comes from SAP’s own certified KPI benchmarks, validated through the SAP HANA Hardware and Cloud Measurement Tools (HCMT). Storage that falls below this threshold will produce I/O bottlenecks under production load — often in ways that don’t surface during pre-production testing because test datasets are smaller and query patterns are less concurrent.

In cloud environments, IOPS provisioning is a deliberate configuration decision, not a default. On AWS, this means provisioned IOPS SSD (io1 or io2) volumes for HANA data and log volumes, not gp2 or gp3 general-purpose volumes at default settings. On Azure, Premium SSD or Ultra Disk configurations are required depending on instance size. On GCP, SSD persistent disks with explicitly provisioned IOPS tiers.

The log volume deserves separate attention. SAP HANA writes redo log entries for every transaction in block sizes ranging from 4KB to 16MB. The log volume must deliver consistent low-latency writes — SAP specifies a latency KPI of less than 1ms for 99% of write operations. Any storage configuration that cannot sustain this under concurrent load will cause data integrity issues under production traffic.

Key storage configuration rules for cloud SAP HANA deployments:

• Data volumes and log volumes must be on separate storage configurations, never co-located.
• Log volumes require synchronous write capability — asynchronous storage replication is not acceptable for the primary log path.
• Backup volumes can use lower-cost storage tiers but must support the throughput required for your backup window.
• Azure storage accounts have a 20,000 IOPS limit per account — deploy SAP systems across storage accounts to avoid hitting this ceiling at scale.

Network Readiness

Network latency between the SAP application server layer and the HANA database must be below 1ms in production configurations. This is a hard requirement, not a guideline — SAP explicitly certifies against this threshold. In cloud deployments, this means your application servers and HANA database instances must reside in the same availability zone, not just the same region.

Bandwidth requirements between application and database layers scale with the number of parallel users and the complexity of queries being executed. Enterprise deployments typically require dedicated network paths — either placement groups (AWS), proximity placement groups (Azure), or equivalent constructs on GCP — to guarantee the low-latency, high-bandwidth connectivity that SAP HANA requires.

DNS Planning: The Most Underestimated Risk in SAP Migration

Of all the domain configuration tasks in an SAP cloud migration, DNS planning generates the most support tickets, causes the most unexpected go-live delays, and receives the least attention during project planning. This section covers why — and what to do about it.

Why DNS Failures Are So Damaging in SAP Migrations

SAP systems are deeply hostname-dependent. The SAP system landscape — application servers, message servers, enqueue servers, HANA database hosts, and all associated interfaces — is configured using hostnames that are baked into profile parameters, transport configurations, RFC destinations, and SSL certificates. When a hostname resolves incorrectly after cutover, the cascade of failures is not isolated to a single component. It propagates across every integration point that references that host.

53% of organizations identify minimizing downtime as their primary challenge — and DNS misconfiguration is one of the most common causes of unplanned downtime extensions during the cutover window. Unlike compute or storage failures, DNS issues often don’t surface until the first real transaction attempts to traverse the network, which means they can be invisible during pre-cutover validation.

TTL Reduction: The 48–72 Hour Rule

DNS Time-to-Live values control how long resolvers cache a DNS record before querying authoritative servers for an updated value. In production SAP environments, DNS TTL values are frequently set to 3,600 seconds (one hour) or higher for stability. At cutover, if you change a DNS record pointing to your new cloud IP addresses, clients that have already cached the old record will continue resolving to the on-premises IP for up to the full TTL duration.

The mitigation is straightforward but requires advance planning: reduce DNS TTL values to 300 seconds (5 minutes) or less, 48 to 72 hours before your cutover window begins. This ensures that by the time you execute the DNS change, no resolver cache holds a record with a multi-hour TTL. After the migration is confirmed stable, TTL values can be returned to production levels.

This step is consistently overlooked because it falls in a planning gap — it’s not a technical infrastructure task, so infrastructure teams don’t own it, and it’s not an application task, so functional consultants don’t flag it. Assign explicit ownership of TTL reduction to your network team with a 72-hour pre-cutover deadline and a verification checkpoint.

Virtual Hostname Configuration

SAP supports the use of virtual hostnames — logical hostnames that are independent of the underlying physical or cloud VM hostname — for HANA database instances and SAP application servers. Virtual hostnames are particularly important in cloud migrations because they allow you to preserve the hostname that existing SAP profile parameters, SSL certificates, and RFC destinations reference, even when the underlying infrastructure changes.

Configuring virtual hostnames in a cloud environment requires:

1. Creating the virtual hostname as a DNS alias (CNAME) or a dedicated A record pointing to the cloud instance’s private IP.
2. Ensuring the virtual hostname is resolvable from every host in the SAP landscape — including application servers, the HANA database, and any connected systems.
3. Configuring the cloud VM’s /etc/hosts file (Linux) or equivalent to include the virtual hostname mapping, in addition to DNS resolution, to provide a fallback resolution path.
4. Verifying that SAP profile parameters (in DEFAULT.PFL and instance profiles) reference the virtual hostname, not the physical cloud VM hostname.
5. Ensuring SSL certificates are issued against the virtual hostname, not the underlying VM hostname.

SSL Certificate Management at Cutover

SSL certificates in SAP environments are bound to hostnames. If your migration changes the fully qualified domain name of any SAP system component — even slightly — certificates must be reissued before go-live or you will encounter SSL handshake failures on every encrypted connection.

Pre-migration SSL planning checklist:

• Audit all current SSL certificates in your SAP landscape, including SAP Web Dispatcher, ICM (Internet Communication Manager), SAP HANA, and any connected middleware.
• Identify any certificates that reference on-premises hostnames or IP addresses that will change post-migration.
• If using virtual hostnames, verify that certificates are issued against the virtual hostname and that the virtual hostname’s DNS record will resolve correctly in the cloud environment.
• For SAN (Subject Alternative Name) certificates covering multiple SAP hosts, verify the SAN list includes all cloud hostnames.
• Stage certificate replacements in non-production environments before the production cutover.
• Do not rely on certificate auto-renewal processes during the cutover window — renew or replace certificates manually and verify them before go-live.

Identity and Access Management: The Highest-Risk Workstream

According to Gartner, 75% of cloud failures are linked to inadequate identity and privilege management — making IAM setup the single highest-risk workstream in any SAP cloud migration. The reason it tops the risk register is structural: IAM changes are not easily reversible after go-live, errors in role mapping or authorization object configuration produce failures that are difficult to diagnose, and incomplete access provisioning can block business-critical processes on day one of production.

What Changes in Cloud IAM vs. On-Premises

On-premises SAP environments typically use a combination of SAP-native authorization objects (managed through SU01, PFCG, and associated tools) and external directory services (Active Directory or LDAP) for network-level authentication.

In cloud deployments, particularly with RISE with SAP or hyperscaler-hosted private edition, a third layer is added: cloud platform identity, which governs access to the cloud infrastructure itself (VMs, storage, network) independently of SAP application-layer access.

This three-layer model — cloud platform IAM, network/directory authentication, and SAP application authorization — must be architected holistically. Gaps between layers produce access scenarios that appear to function in testing (where permissions are often broader) but fail in production (where least-privilege principles are enforced).

SAP BTP Identity and Authentication Service

For cloud deployments using SAP Business Technology Platform (BTP), the Identity Authentication Service (IAS) becomes the central identity broker. IAS supports SAML 2.0 and OAuth 2.0 federation and can proxy authentication requests to your existing corporate identity provider (Azure AD, Okta, Ping, etc.) while enforcing SAP-specific authorization requirements.

Key IAS configuration tasks for migration:

• Establish trust between IAS and your corporate IdP before cutover — do not attempt to configure federation during the production migration window.
• Map corporate user attributes (email, user ID, department) to SAP authorization-relevant fields through IAS attribute mappings.
• Configure multi-factor authentication (MFA) policies before go-live if your security posture requires it — retrofitting MFA post-migration with an active user population is significantly more disruptive than enabling it at go-live.
• For S/4HANA Cloud Public Edition, users are provisioned through IAS and must have business roles assigned before they can log in — role assignment is not automatic and must be part of your go-live checklist.

Emergency Access and Break-Glass Accounts

Cloud migrations introduce a specific IAM risk that on-premises deployments rarely face: the possibility that normal authentication pathways become unavailable during or immediately after cutover, while the system is simultaneously under go-live load. DNS failures, network connectivity issues, or IdP federation misconfigurations can all produce scenarios where legitimate users cannot authenticate through normal channels.

Mitigate this risk by establishing verified break-glass access before cutover:

• Maintain at least one SAP emergency user account with direct local authentication (not federated through IAS or AD) that is verified functional in the new cloud environment.
• Document the break-glass account credentials in a secure, offline location accessible to the migration lead.
• Test break-glass access during UAT, not for the first time during the production cutover.
• Disable or expire break-glass accounts immediately after the go-live stabilization period to maintain your security posture.

The Infrastructure and DNS Preparation Timeline

The most common sequencing mistake in SAP cloud migrations is treating infrastructure provisioning and DNS/domain configuration as sequential workstreams — finish the infrastructure, then configure DNS. In practice, these workstreams must run in parallel, because DNS propagation and SSL certificate issuance introduce time delays that cannot be compressed regardless of how quickly the infrastructure work is completed.

A realistic preparation timeline for a production SAP cloud migration looks like this:

• T-minus 4 weeks: Complete cloud infrastructure provisioning (VMs, storage, networking, security groups). Begin DNS planning — identify all hostnames that will change, all TTL values that need to be reduced, and all SSL certificates that will require reissuance.
• T-minus 3 weeks: Begin non-production system migration and testing. Initiate SSL certificate reissuance for all hostnames that will change. Configure virtual hostnames in the cloud environment and verify DNS resolution.
• T-minus 72 hours: Reduce DNS TTL values for all production SAP hostnames to 300 seconds or less. Verify that TTL reduction has propagated to all relevant resolvers. Complete final IAM configuration review — verify role assignments, test break-glass accounts, confirm federation connectivity.
• T-minus 24 hours: Complete final data synchronization. Execute pre-cutover validation checklist. Confirm storage IOPS performance under simulated production load. Verify SSL certificate validity and hostname binding.
• Cutover window: Execute DNS record changes, validate resolution from multiple network locations, run smoke tests across all critical SAP transactions. 76% of organizations that prioritize automation in their strategies cite it as a key factor in reducing downtime and human error at cutover — have your automated validation scripts ready before you begin, not while you’re executing.
• T-plus 24 hours: Monitor system performance and error logs intensively. Do not disable on-premises systems until this monitoring window has passed. Restore DNS TTL values to production levels once stability is confirmed.

A Note on Realistic Project Economics

Planning a migration without a frank acknowledgment of the cost and timeline pressures organizations face is not useful guidance — it’s optimism theater. 62% of organizations cite high project cost as the top barrier to getting started, and 55% cite project duration as a major concern — a figure that has risen sharply from 37% in 2024 as organizations increasingly grapple with the reality of extended timelines for phased transitions, custom code refactoring, and business process reengineering.

The public cloud adoption rate for new implementations has grown from 23.7% in 2021 to 39.2% in early 2024, with an average of 89.3% of total five-year costs classified as operational rather than capital expenditure — reducing upfront requirements significantly. But the ROI case only holds if the migration is executed effectively. Organizations that follow a structured approach reduce timelines by 24 to 36% and decrease costs by 18 to 27% compared to unstructured implementations.

The gap between a migration that delivers on its business case and one that becomes a multi-year remediation project is, in most cases, a planning gap — not a technology gap.