Migration Strategies: The Decision Framework
Compare lift-and-shift, replatform, and reimagine strategies for SAP migration to Azure. Understand the decision matrix of DMO, classical, heterogeneous, and export/import approaches with downtime tolerance as a key factor.
The three migration philosophies
Before we get into specific tools, let’s understand the three fundamental approaches to moving SAP to Azure. Each represents a different trade-off between effort, risk, and transformation value.
Think of it like moving to a new house.
Lift-and-shift is packing your furniture into a truck and putting it in the exact same arrangement in the new house. Fast, cheap, but you still have the same old couch. Replatform is moving to the new house and upgrading some furniture along the way — new kitchen appliances, same living room layout. Reimagine is selling everything, hiring an interior designer, and furnishing the new house from scratch with modern pieces.
| Factor | Lift-and-Shift | Replatform | Reimagine |
|---|---|---|---|
| What changes | Infrastructure only — same OS, DB, SAP version | Infrastructure plus database (e.g., Oracle to HANA) and/or SAP version upgrade | Everything — new S/4HANA implementation, re-engineered processes |
| Typical downtime | Hours (VM-level migration or backup/restore) | Hours to days (depends on database size and conversion complexity) | Weeks of parallel running (legacy and new system run side by side) |
| Risk level | Low — minimal changes, easy rollback | Medium — database conversion adds complexity | High — new implementation, data migration, process redesign |
| Business value | Low — same system, new location | Medium — modernized database, potential performance gains | High — optimized processes, modern UX, clean data |
| When to use | Urgent datacenter exit, hardware refresh, move first and modernize later | ECC to S/4HANA conversion, database platform change needed | Major business transformation, legacy system retirement, clean-start opportunity |
| SAP tools | Backup/restore, ASR, HSR-based migration | DMO with SUM, classical migration, heterogeneous SWPM | New installation plus data migration (LSMW, LTMC, or third-party) |
🏗️ Raj looks at Deepak’s budget spreadsheet. “Deepak wants us to move first and modernize later — that sounds like lift-and-shift.”
☁️ Mei pushes back gently. “I understand the budget pressure, but think about it: if you lift-and-shift ECC on Oracle to Azure, you still need to migrate to S/4HANA on HANA before 2027 when mainstream maintenance for ECC ends. That is two migrations. A replatform approach using DMO lets you do infrastructure migration and S/4HANA conversion in one swing. Sometimes the two-phase approach makes sense, but sometimes it is just two projects instead of one.”
The two-phase question
A common exam scenario is deciding between:
- Single migration — Move to Azure AND convert to S/4HANA/HANA in one project (replatform using DMO)
- Two-phase migration — First, lift-and-shift to Azure (same platform). Then, convert to S/4HANA/HANA on Azure in a second project
Two-phase is preferred when:
- The datacenter exit deadline is urgent and cannot wait for S/4HANA preparation
- Custom code remediation for S/4HANA will take months and cannot be completed before the move
- You want to derisk by separating infrastructure migration from application modernization
Single migration is preferred when:
- ECC end-of-mainstream-maintenance is approaching and you need S/4HANA soon
- You want to avoid two separate downtime windows
- The assessment shows your system is relatively ready for S/4HANA (minimal custom code changes)
The migration methods: DMO, classical, heterogeneous, and export/import
Now let’s get specific about the tools. Each method has a different sweet spot.
| Method | What it does | When to use it | Downtime impact |
|---|---|---|---|
| DMO with SUM | Combines SAP version upgrade and database migration (e.g., ECC on Oracle to S/4HANA on HANA) in a single execution | Replatform scenarios — upgrading SAP version and changing database in one step | Medium to long — proportional to database size, can be optimized with near-zero downtime options |
| Classical Migration (homogeneous) | Moves SAP system to a new server with the SAME database platform. Uses backup/restore or SAP tools | Lift-and-shift — same SAP version, same database, new infrastructure | Short — primarily the time to restore the database and reconfigure |
| Heterogeneous System Copy (SWPM) | Exports SAP data from one database platform and imports into a different one using SAP Software Provisioning Manager | Database platform change without SAP version upgrade, or when DMO is not applicable | Long — full data export and import, proportional to database size |
| Export/Import | Exports specific data objects and reimports them into a fresh SAP installation | Greenfield implementations with selective data migration, system consolidation | Very long — involves a new system build plus data migration and validation |
DMO (Database Migration Option) with SUM
DMO is the flagship replatform tool. It uses SAP’s Software Update Manager (SUM) to perform a version upgrade and database migration simultaneously. For PrecisionSteel, DMO would convert ECC 6.0 on Oracle to S/4HANA on HANA in a single execution.
Key DMO characteristics:
- Runs inside SUM — the same tool used for SAP patches and upgrades
- Can migrate the database platform (Oracle, SQL Server, DB2 to HANA) while upgrading the SAP version
- Supports a “DMO with System Move” option that also relocates the system to a new server (Azure VM)
- Downtime is proportional to database size but can be reduced with optimization techniques
- Requires the source system to be at certain minimum patch levels
Classical migration — the lift-and-shift workhorse
Classical (homogeneous) migration keeps everything the same except the infrastructure. Common techniques:
- Backup and restore — Back up the database on-premises, copy to Azure, restore on an Azure VM
- HANA System Replication (HSR) — Set up replication from on-premises to Azure, then cut over (covered in detail in Module 6)
- Azure Site Recovery — Replicates VMs at the hypervisor level for non-HANA workloads
🏗️ Raj recognizes this pattern. “That is basically what we do when we refresh hardware — backup, restore, reconfigure. We have done this a dozen times.”
☁️ Mei nods. “Exactly — and that familiarity is a feature, not a bug. Classical migration has the lowest risk because you are doing something your team already knows.”
Heterogeneous system copy — changing the database
When you need to change the database platform but not the SAP version, the heterogeneous system copy using SAP Software Provisioning Manager (SWPM) is the tool. It exports all SAP data from the source database in a platform-independent format and imports it into the target database.
The downside: it can be very slow for large databases because it exports and imports all data row by row.
The decision matrix
How do you choose? The decision comes down to four questions:
- Are you changing the SAP version? (e.g., ECC to S/4HANA) — If yes, DMO or export/import are your options.
- Are you changing the database platform? (e.g., Oracle to HANA) — If yes, DMO, heterogeneous SWPM, or export/import.
- How much downtime can you tolerate? — Classical and HSR-based approaches minimize downtime. DMO downtime scales with database size. Export/import has the longest downtime.
- Is this a clean start or a system copy? — If clean start with selective data, go export/import. If copying the existing system, use DMO or classical.
Exam tip: The decision tree
When an exam question describes a migration scenario, identify these four factors first. The combination almost always points to one method. For example: “ECC on SQL Server needs to become S/4HANA on HANA with minimal downtime” points to DMO with near-zero downtime optimization. “SAP system needs to move to Azure with no version or database changes” points to classical migration.
Downtime tolerance: The hidden decision driver
Downtime tolerance often overrides technical preference. A manufacturing company that runs 24/7 production cannot afford a 48-hour migration window. A financial services company with a weekend batch processing window might accept 36 hours.
Techniques to reduce downtime:
- HSR-based migration — Replicates data continuously, final cutover takes minutes
- DMO with near-zero downtime — Uses SUM’s optimization features to minimize the conversion window
- Parallel execution — Running multiple export/import streams simultaneously
- Pre-copy and delta sync — Copying bulk data before the cutover window, then syncing only changes during downtime
🏗️ Raj checks his notes. “PrecisionSteel runs three shifts. Our maintenance window is Saturday midnight to Sunday 6 AM — six hours.”
☁️ Mei does the math. “With a 2 TB database, DMO will need more than six hours for the full conversion. We either need to extend the window, use a two-phase approach where we lift-and-shift first using HSR (minutes of downtime), or explore DMO with near-zero downtime techniques. This is exactly why assessment matters — the downtime constraint shapes the entire strategy.”
Knowledge check
PrecisionSteel's datacenter lease expires in 3 months, but the S/4HANA custom code remediation will take 8 months. What migration approach should Raj recommend?
Raj is evaluating migration tools for PrecisionSteel's ECC-to-S/4HANA conversion. Which SAP migration method combines a version upgrade and a database platform change into a single execution?
Mei is advising a company that runs SAP BW on Oracle and needs to migrate to BW/4HANA on Azure. The database is 8 TB and they can tolerate a 48-hour downtime window. Which approach is most appropriate?
Summary
You now have a framework for choosing the right migration strategy. Lift-and-shift is fastest and lowest risk but adds no modernization value. Replatform (DMO) delivers infrastructure and database modernization in one swing. Reimagine provides maximum transformation but at maximum cost and time. The decision hinges on four factors: version change, database change, downtime tolerance, and whether you want a clean start.
Next, we explore RISE with SAP — an entirely different operating model where SAP manages the infrastructure for you.
🎬 Video coming soon