Introduction
Most enterprises treating SAP lift and shift as a straightforward "copy and paste to the cloud" discover the hard way that it isn't. A misplanned migration can freeze finance operations, break compliance workflows, and stall supply chain processes for days — risks that SAP Basis administrators, IT architects, and CIOs in BFSI, FMCG, and IT services cannot afford.
At its simplest, SAP lift and shift migration moves an existing SAP landscape — applications, databases, and configurations — from on-premises or another hosting environment to Azure with minimal changes to application logic.
The term is widely used but consistently misread. Organizations routinely underestimate how much changes beneath the surface. The application logic stays intact — but the entire infrastructure layer must be rebuilt for Azure: network topology, storage architecture, high availability design, and security controls all require deliberate redesign.
This guide covers everything needed to plan and execute that rebuild successfully — from pre-migration assessment and Azure sizing to cutover execution and post-migration validation.
TL;DR
- SAP lift and shift (rehosting) moves the SAP landscape to Azure VMs with minimal changes to business logic or customisations
- Fastest migration path to cloud but does not modernise SAP applications or optimise the underlying architecture
- Requires careful assessment of OS, DBMS, and workload dependencies before migration begins
- Network, storage, HA/DR, and security must be redesigned for Azure — even when the application itself stays unchanged
- Not always the right approach—organisations planning to upgrade to SAP S/4HANA or change databases should consider alternative methods
What Is SAP Lift and Shift Migration to Azure?
Lift and shift, officially termed "rehosting" by Microsoft, relocates the SAP landscape—including the DBMS, application servers, and dependent components—to Azure virtual machines with no code changes, no database engine changes, and no architectural redesign of SAP itself.
This approach preserves operational continuity on cloud infrastructure, cutting on-premises hardware costs and unlocking Azure's scalability and global data centre reach—without the time and risk of a full SAP transformation.
How it differs from related approaches:
- Replatforming makes modest adjustments to take advantage of Azure-native services, such as switching to managed databases
- Rearchitecting rebuilds the SAP landscape from the ground up using cloud-native capabilities
- DMO (Database Migration Option) bundles an SAP version upgrade and database migration into a single step
Why Organisations Choose Lift and Shift for SAP on Azure
Business Drivers and Deadlines
Specific business drivers push enterprises toward cloud migration. SAP ECC end-of-mainstream maintenance ends on 31 December 2027, with extended maintenance available until 2030 at a premium surcharge of two percentage points. Rising on-premises infrastructure costs, hardware refresh cycles, and data centre consolidation initiatives create urgency—and lift and shift offers the lowest-risk, fastest path when time pressure is high.
The SAP-Microsoft Partnership Advantage
Azure is a certified platform for SAP HANA and SAP NetWeaver workloads. SAP-certified VM families — M-series, Mv2, and Mv3 — are purpose-built for HANA's in-memory demands, reducing compatibility risk across the stack. The SAP HANA Hardware Directory lists specific Azure VM SKUs, validation dates, and supported configurations.
Operational Consequences of Delay
Delayed migration carries real cost. Organisations that hold off face:
- Escalating hardware maintenance costs as infrastructure ages
- Unsupported OS and DBMS configurations that breach vendor SLAs
- Increased security exposure from unpatched, end-of-life components
Migration without proper planning introduces its own risks: broken integrations, compliance gaps, and performance degradation that can surface weeks after go-live.
How SAP Lift and Shift Migration to Azure Works
SAP lift and shift migration to Azure follows four broad stages: assess the existing landscape, design and provision the Azure environment, execute the migration, then validate and cut over. Each stage feeds back into the others — expect iteration, not a straight line from start to finish.
Phase 1: Assess the SAP Platform and Dependent Workloads
Assessment involves auditing OS versions and Azure compatibility, identifying the current DBMS and whether it is supported in Azure as-is, cataloguing dependent workloads (non-SAP applications, middleware like SAP PI/PO, file mounts, cron jobs) that are tightly coupled to the SAP environment, and determining whether any remediation is required before migration begins.
Critical activities include:
- Discovering all hosts, DBMS versions, OS versions, and application servers
- Identifying dependencies between SAP and non-SAP systems using tools like Azure Migrate
- Conducting readiness checks to identify unsupported components requiring remediation
- Grouping interdependent workloads into logical migration waves
Peripheral dependencies — file mounts, scheduled jobs, middleware integrations — are the most common source of post-migration outages. Map these explicitly during assessment, not as an afterthought.
Phase 2: Design the Azure Environment and Size Correctly
Sizing considerations are one of the most common failure points. Key design decisions include:
Compute sizing:
- Select SAP-certified VMs from the SAP HANA Hardware Directory
- M-series and Mv2-series for SAP HANA workloads
- E-series and D-series for smaller SAP NetWeaver application servers
Storage design:
- Azure Premium SSD v2 or Ultra Disk for HANA data/log volumes
- Recommended starting sizes:
/hana/data= 1.2x VM memory;/hana/log= 0.5x VM memory (capped at 500 GiB for VMs >1 TiB) - Performance targets for VMs <1 TiB: 425 MB/s and 3,000 IOPS for
/hana/data; 275 MB/s and 3,000 IOPS for/hana/log - Stripe size recommendations: 256 KB for
/hana/data, 64 KB for/hana/log
High availability and disaster recovery:
- Deploy across Azure Availability Zones (or Availability Sets if zones unavailable)
- Use SAP HANA System Replication (HSR) with Pacemaker clustering for HA
- Standard Azure Load Balancer provides stable virtual IP for cluster failover
- Azure Site Recovery for application tier replication (not for database VMs)
Network and security:
- ExpressRoute for on-premises connectivity
- VNets, subnets, and Network Security Groups (NSGs) for segmentation
- Azure Hybrid Benefit or BYOL licensing to reduce costs on Windows Server and SQL Server
Right-sizing is critical on both ends. Undersizing causes performance bottlenecks and SLA failures; oversizing runs up costs unnecessarily, since Azure's consumption-based model means every over-provisioned core and gigabyte shows up on the bill.
Phase 3: Execute the Migration and Validate
Two primary SAP migration methods are available:
Classical migration (SWPM):
- Uses SAP Software Provisioning Manager for homogeneous system copy
- Suited when OS and DBMS are already Azure-compatible
- Two-phase process: export source database, then install target system on Azure VMs
- For a true lift and shift, this is typically the method of choice
DMO (SUM with Database Migration Option):
- SAP Software Update Manager creates a shadow repository, migrates the database to HANA, and upgrades SAP simultaneously
- Suited when DBMS or OS is not Azure-compatible or when an S/4HANA upgrade is planned
- Combines update and migration into a single downtime window
Post-Migration Validation
Post-migration validation steps:
- Functional testing of transactions and reports
- Performance benchmarking against baseline metrics
- Integration testing for dependent systems
- Cutover planning with detailed runbook and fallback options
- Azure Monitor for SAP solutions centralises telemetry from application, database, OS, and infrastructure
- Azure Center for SAP solutions provides quality checks via Azure Advisor
Key Factors That Affect SAP Lift and Shift Migration Success
Existing Environment Complexity
Source environments that deviate from standard SAP configurations increase migration risk and effort. Common deviations include custom OS tuning, non-standard storage mounts, third-party workload integrations, and long-lived unsupported configurations. Organisations should map the full "as-is" environment before assuming a simple rehost is feasible.
OS/DBMS Compatibility
If the source OS (e.g., older versions of SUSE, RHEL, or Windows) or DBMS (e.g., Oracle, DB2, MaxDB) is not supported in Azure, remediation is required before or during migration. This can unexpectedly shift a lift and shift into a replatforming exercise—a frequent source of scope creep.
SAP ECC can be rehosted to Azure without a HANA database. Supported DBMS options include:
- Oracle Database
- Microsoft SQL Server
- IBM Db2 for LUW
- SAP ASE
- SAP MaxDB
Definitive support information is found in SAP Note 1928533 and the SAP Product Availability Matrix (PAM).
Network and Security Redesign Requirements
On-premises network configurations—firewall rules, port mappings, web dispatchers, load balancers, Active Directory integrations—do not map directly to Azure equivalents. Security hardening requirements on Azure (SSL enforcement, encryption at rest, NSG rules, identity and access management) may alter application behaviour if not planned and tested carefully.
SAP systems are highly sensitive to network performance. Inadequate throughput between application and database servers, high latency to critical services, or misconfigured NSGs can severely degrade system performance.
Regulatory Compliance and Integration Continuity
Enterprises running SAP for finance operations—especially those subject to e-invoicing mandates, VAT compliance, or GST regulations in markets like India, Saudi Arabia, UAE, or the EU—must ensure that tax and compliance integrations remain functional post-migration.
Key compliance mandates include:
- India (GSTN/IRP): B2B invoices require JSON payload validation and IRN generation via the IRP
- Saudi Arabia (ZATCA): The two-phase "Fatoora" mandate requires UBL XML integration with ZATCA's platform
- UAE (FTA): Phased rollout from July 2026 requires use of FTA-Accredited Service Providers
- EU: Directive 2014/55/EU requires EN 16931-compliant e-invoices for B2G transactions
Any compliance platform integrated with SAP—such as Cygnet.One, which processes 15-19% of India's e-invoices and holds accreditations across ZATCA, FTA, HMRC, and GSTN—must be validated as part of migration testing to prevent compliance gaps at cutover.
Scale, Data Volumes, and Downtime Tolerance
Large SAP landscapes with high data volumes require careful planning around migration windows. The trade-off between minimising downtime (using parallel run or phased migration strategies) and migration complexity is significant—business-critical SAP systems often have narrow maintenance windows that constrain approach options.
Typical timelines:
- Simple, single-system landscapes: several weeks to a few months
- Complex, multi-system landscapes: several months to over a year
- Case study examples: 180 systems with 74 TB migrated in six months; 92 TB system with 20-hour production cutover
Common Misconceptions—and When Lift and Shift Isn't the Right Approach
"Lift and Shift Means Nothing Changes"
The most common misconception is that lift and shift is a pure copy-paste exercise. Application logic and business processes stay intact — but the entire underlying environment must be rebuilt on Azure's architecture, including:
- Network topology and security boundaries
- Storage architecture and HA/DR design
- Monitoring and observability tooling
- SaaS equivalents for on-premises services like DNS and Active Directory
Teams that overlook this consistently encounter broken integrations and performance issues after go-live.
Confusion Between Lift and Shift and Replatforming
Organisations often start planning a lift and shift but end up in a replatforming project once environmental differences surface. Early awareness of this scope expansion—especially around cloud-native HA, DR options, and storage architecture—prevents timeline and budget overruns.
When Lift and Shift Is the Wrong Tool
Lift and shift is not appropriate when:
- The organisation is planning to move to SAP S/4HANA (which requires a database migration to HANA and functional changes)
- The current DBMS is not Azure-certified
- Significant SAP version upgrades are required
- The source OS or DBMS is not supported on Azure
- The workload is already experiencing performance, architectural, or stability issues
In these scenarios, DMO or a full rearchitecting approach is more appropriate. Defaulting to lift and shift without assessing fit means missing the chance to resolve existing problems while the migration is already underway.
Wrong Reasons for Choosing Lift and Shift
Signals that lift and shift is being chosen for the wrong reasons include:
- Urgency to exit a data centre without a proper assessment
- Assuming it costs less than alternatives without running a TCO comparison
- Treating it as a temporary measure with no post-migration optimisation plan
Each of these shortcuts trades short-term speed for long-term rework — and the cloud costs that follow rarely justify the trade-off.
Frequently Asked Questions
What is the difference between SAP lift and shift and replatforming on Azure?
Lift and shift (rehosting) moves SAP to Azure VMs with no architectural changes, while replatforming involves making targeted adjustments to take advantage of Azure-native services—such as switching to managed databases or cloud-native load balancers—during the migration process.
Does lift and shift migration affect SAP business processes or custom configurations?
Business processes, ABAP customisations, and SAP configurations are preserved in a lift and shift—only the underlying infrastructure changes. However, tightly coupled environment dependencies (ports, mounts, middleware integrations) can indirectly affect business processes if not carefully mapped and tested.
What Azure VM types are recommended for SAP HANA workloads in a lift and shift?
Azure M-series and Mv2-series VMs are SAP-certified for HANA in-memory workloads. VM selection should be validated against the SAP HANA Hardware Directory for Azure. Storage must be sized with HANA-specific I/O requirements in mind.
How long does a SAP lift and shift migration to Azure typically take?
Timelines depend on landscape complexity, data volume, and available migration windows. Simple landscapes may take several weeks to a few months, while complex multi-system environments can extend beyond a year—with assessment and design phases often taking longer than the migration itself.
Is lift and shift suitable for migrating SAP ECC or SAP S/4HANA to Azure?
Lift and shift is commonly used for SAP ECC migrations to Azure where no version upgrade or DBMS change is planned. For SAP S/4HANA migrations, which require a HANA database and may involve functional changes, DMO or a greenfield/brownfield approach is typically more appropriate.
What are the main risks of a SAP lift and shift migration to Azure?
The three most common risks are:
- Incomplete dependency mapping — leads to broken integrations after cutover
- Incorrect VM or storage sizing — causes post-migration performance degradation
- Network/security mismatches — disrupts application availability at go-live
Each risk is addressable with a structured pre-migration assessment.
