Migration Execution: DMO, Classical, and Beyond

From strategy to execution

In Module 3, you learned when to use DMO, classical, or heterogeneous approaches. Now we get into the hands-on details of each method — how they actually work, what tools are involved, and what to watch for during execution.

🏗️ Raj rolls up his sleeves. “Alright, we have assessed the landscape, chosen our strategy. Now tell me exactly how the migration runs.”

☁️ Mei opens the SAP Software Logistics documentation. “Let’s walk through each method step by step.”

DMO with SUM: The replatform workhorse

The Database Migration Option (DMO) runs inside the Software Update Manager (SUM). Think of SUM as the Swiss Army knife for SAP system changes — it handles patches, upgrades, and with the DMO option, database migrations.

DMO execution phases

Phase 1: Preparation (can be online)

• SUM reads the source system configuration and SAP upgrade stack
• Extracts repository objects and prepares the target schema on HANA
• Imports software components that can be processed without downtime
• The source system remains available to users during this phase

Phase 2: Downtime execution

• Source system is locked — users are disconnected
• Remaining data is migrated from the source database to HANA
• SAP upgrade transformations are applied
• This is the actual downtime window — duration depends on database size and optimization settings

Phase 3: Post-processing (system back online)

• SUM finalizes database indexes, adjusts runtime objects
• System verification checks run
• The system restarts on HANA with the new SAP version

DMO with System Move

When using DMO with System Move to migrate to Azure:

• The source system runs on-premises with the original database
• The target HANA database runs on an Azure VM
• SUM coordinates data transfer between the two environments
• A reliable, high-bandwidth network connection between on-premises and Azure is critical (ExpressRoute recommended)
• After completion, the Azure VM becomes the new production system

Question

What are the three phases of a DMO with SUM execution?

Click or press Enter to reveal answer

Answer

1) Preparation phase — can run while the system is online, analyzes the system and prepares migration components. 2) Downtime execution — system is locked, data migrates to HANA and SAP upgrade transformations apply. This is the actual downtime window. 3) Post-processing — finalizes indexes and runtime objects, system restarts on HANA with the new version.

Click to flip back

💡 Exam tip: DMO prerequisites

DMO requires specific minimum SAP kernel and SUM versions on the source system. The source system must be at a certain patch level before DMO can run. If an exam question mentions an old, unpatched source system, the answer may involve first applying prerequisite patches before DMO can proceed.

Optimizing DMO downtime

For large databases, the downtime phase can be significant. Optimization techniques include:

• Table splitting — Large tables are divided into chunks that migrate in parallel, reducing elapsed time
• Parallel migration streams — Multiple tables migrate simultaneously using multiple worker processes
• Near-zero downtime (nZDT) — An advanced SUM option that uses application-level replication to minimize the conversion window to minutes instead of hours
• Pre-migration of read-only tables — Historical data tables that will not change can be migrated during the preparation phase while the system is still online

🏗️ Raj does a quick calculation. “Our 2 TB database with four parallel streams — what kind of downtime are we looking at?”

☁️ Mei estimates. “With good optimization, probably 8-12 hours for a 2 TB conversion. The near-zero downtime option could bring that down significantly, but it adds complexity and requires more preparation. For your six-hour maintenance window, we should seriously look at HSR-based migration for the infrastructure move, followed by DMO conversion once on Azure.”

Question

Name three techniques to reduce DMO downtime for large databases.

Click or press Enter to reveal answer

Answer

1) Table splitting — divides large tables into chunks for parallel migration. 2) Parallel migration streams — migrates multiple tables simultaneously. 3) Near-zero downtime (nZDT) — uses application-level replication to minimize the conversion window. Additional options include pre-migrating read-only historical tables during the online preparation phase.

Click to flip back

Classical migration: Backup, restore, and go

Classical (homogeneous) migration is the simplest path when you are keeping the same SAP version and database platform. You are essentially rebuilding the same system on Azure infrastructure.

Backup and restore workflow

1. Prepare the target Azure VM — Deploy the VM with the correct OS, install the database software, configure storage
2. Take a full database backup on the source system
3. Transfer the backup to Azure — Using AzCopy, ExpressRoute data transfer, or Azure Data Box for very large datasets
4. Restore the database on the Azure VM
5. Reconfigure SAP — Update host names, adjust profiles, configure the SAP instance to start on the new host
6. Validate — Run SAP system checks, verify application functionality

Data transfer options for large databases:

• AzCopy over ExpressRoute — For databases up to a few TB, fast enough if you have good bandwidth
• Azure Data Box — For databases above 10 TB or when network bandwidth is limited. Microsoft ships you a physical storage device, you load the backup, ship it back
• Compressed and incremental — Take a full backup early, then an incremental backup just before cutover to minimize the data transferred during the downtime window

Question

What is Azure Data Box and when would you use it for SAP migration?

Click or press Enter to reveal answer

Answer

Azure Data Box is a physical storage device shipped by Microsoft for offline data transfer to Azure. Use it when database backups are very large (10+ TB) or when network bandwidth is too limited for timely online transfer. You load the backup onto the device, ship it to an Azure datacenter, and Microsoft uploads the data to your storage account.

Click to flip back

Heterogeneous system copy with SWPM

The SAP Software Provisioning Manager (SWPM) handles heterogeneous system copies — changing the database platform without changing the SAP version.

How it works

1. Export — SWPM exports all SAP data from the source database into platform-independent files (R3load format)
2. Transfer — Export files are copied to the Azure target system
3. Import — SWPM imports the data into the new target database (e.g., HANA)

The critical limitation: this is a full data export and import. For a 5 TB database, every row of every table is exported, transferred, and re-imported. It is thorough but slow.

When SWPM is the right choice

• Database platform change WITHOUT an SAP version upgrade (DMO is not applicable because there is no version upgrade to combine with)
• When DMO prerequisites cannot be met (source system too old or too heavily customized)
• Unicode conversion combined with database migration (SWPM handles Unicode conversion natively)

Migration methods: Execution details

Aspect	DMO with SUM	Classical (Backup/Restore)	Heterogeneous SWPM	Export/Import (Greenfield)
Primary tool	SUM (Software Update Manager)	Database-native backup tools + AzCopy	SWPM (Software Provisioning Manager)	New SAP installation + LSMW/LTMC/third-party
SAP version change	Yes — upgrade included	No — same version	No — same version	Yes — new installation at target version
Database change	Yes — migrates to HANA	No — same database	Yes — changes database platform	Yes — new installation chooses target DB
Downtime driver	Database size and upgrade complexity	Backup transfer and restore time	Full data export and import	New system build plus data validation
Rollback strategy	Restore source system from backup	Source system still exists on-premises	Source system still exists on-premises	Keep legacy system running until validation complete
Network requirement	High bandwidth between source and target (ExpressRoute)	Sufficient for backup transfer	Sufficient for export file transfer	Minimal — systems are independent

Cutover planning

The cutover is the actual migration event — the period when the old system goes down and the new system comes up. Poor cutover planning is the number one cause of migration failures.

Cutover checklist

1. Define the downtime window — Get business sign-off on the exact start and end times
2. Document every step — Create a minute-by-minute runbook with responsible person, expected duration, and verification checkpoint for each step
3. Define rollback triggers — At which point do you abort and fall back to the source system? What are the criteria?
4. Rehearse — Run the cutover on a sandbox or QA system first. Measure actual timings.
5. Communication plan — Who gets notified at each stage? How do users know when the system is back?
6. DNS and connection updates — SAP GUI connection strings, web dispatcher URLs, RFC destinations, printer configurations all need to point to the new system

🏗️ Raj nods vigorously. “I have seen migrations fail because nobody updated the RFC destinations. All the batch jobs kept trying to call the old system.”

☁️ Mei adds it to the list. “Exactly. And that is why rehearsal on a non-production system is non-negotiable. You discover those hidden dependencies before they bite you in production.”

Question

What is the most important step in cutover planning for SAP migration?

Click or press Enter to reveal answer

Answer

Rehearsal on a non-production system. Running the cutover end-to-end on a sandbox or QA system reveals hidden dependencies (RFC destinations, batch job configurations, printer setups), validates the runbook timings, and gives the team confidence. It also provides realistic downtime estimates for business stakeholders.

Click to flip back

💡 Exam tip: Cutover scenarios

Exam questions often present a cutover scenario with a time constraint and ask you to identify the correct sequence of steps or the appropriate rollback point. Practice thinking through the sequence: stop system, take final backup (rollback point), execute migration, verify, update connections, release to users. The final backup before execution is always the rollback point.

Selecting the right tool: A quick decision guide

When an exam question describes a migration scenario, ask yourself:

• Changing SAP version? → DMO (with SUM) or greenfield export/import
• Changing database platform only? → Heterogeneous SWPM or DMO (if combining with upgrade)
• Same version, same database, new infrastructure? → Classical backup/restore or HSR
• Tight downtime window? → HSR-based approach (covered in Module 6)
• Clean start wanted? → Greenfield installation with selective data migration

Question

What is the key difference between DMO and a heterogeneous system copy using SWPM?

Click or press Enter to reveal answer

Answer

DMO combines database migration WITH an SAP version upgrade in a single execution. Heterogeneous system copy (SWPM) changes the database platform WITHOUT upgrading the SAP version. DMO is typically faster and preferred when a version upgrade is also needed. SWPM export/import is used when only the database platform needs to change.

Click to flip back

Knowledge check

Knowledge Check

PrecisionSteel needs to convert ECC 6.0 on Oracle to S/4HANA on HANA while simultaneously moving to an Azure VM. Which tool and option should Raj use?

ASWPM heterogeneous system copy to change the database, then a separate SAP upgradeBDMO with SUM using the System Move optionCAzure Site Recovery to replicate the VM, then upgrade SAP in-placeDClassical backup/restore followed by an in-place database migration

Check Answer

Knowledge Check

Raj is planning the DMO execution timeline for PrecisionSteel's migration. During a DMO execution, at which phase is the SAP system unavailable to users?

APreparation phase — the system is locked from the startBDowntime execution phase — data migration and upgrade transformations run while the system is lockedCPost-processing phase — the system is unavailable until all indexes are rebuiltDAll three phases require the system to be offline

Check Answer

Knowledge Check

Mei is advising a customer with a 15 TB SAP database and limited network bandwidth to Azure. What is the recommended approach for transferring the database backup?

AUse AzCopy to transfer the backup over a standard internet connectionBUse Azure Data Box for offline data transfer to AzureCCompress the backup to under 1 TB and transfer via VPNDUse Azure Blob Storage REST API for a streaming upload

Check Answer

Summary

You now understand the execution mechanics of each migration method: DMO with SUM for combined upgrade and database migration, classical backup/restore for same-platform moves, heterogeneous SWPM for database platform changes without version upgrades, and the critical importance of cutover planning with rehearsal. The System Move option in DMO enables direct migration to Azure VMs during the conversion.

Next, we explore HANA System Replication — a powerful technique for near-zero-downtime migration to Azure.

🎬 Video coming soon