Post-Migration: Validation, Health, and HLI Migration
Complete the migration lifecycle with post-migration validation checklists, SAP transaction codes for health checks, performance baseline comparison, Azure-specific post-migration steps, and the special workflow for migrating from HANA Large Instances to Azure VMs.
Migration is not done until validation says so
🏗️ Raj wipes the sweat off his forehead. “The takeover worked, HANA is running on Azure, SAP is up. Are we done?”
☁️ Mei shakes her head firmly. “The system is running, but we are not done. Post-migration validation is what separates a successful migration from a ‘we think it worked’ migration. We need to prove — with data — that the system performs at least as well as before, that all integrations work, and that nothing was lost or corrupted.”
Think of it like a test drive after a car repair.
When the mechanic says your car is fixed, you do not just take their word for it. You drive around the block, check the brakes, test the AC, listen for weird noises. Post-migration validation is your test drive — you methodically check every system to make sure it performs the way it should before you hand the keys back to the users.
The validation checklist
1. SAP system health checks
SAP provides built-in transaction codes that every Basis administrator uses for health monitoring. After migration, run these immediately:
ST03N — Workload Analysis Shows dialog step response times, database request times, and overall system throughput. Compare these numbers against your pre-migration Early Watch Alert baselines. Response times should be equal or better on Azure.
ST06 — Operating System Monitor Displays CPU utilization, memory usage, swap activity, and disk I/O from the OS perspective. On Azure, verify that:
- CPU is not throttled or consistently above 80 percent
- Memory utilization aligns with your HANA sizing calculations
- Disk I/O latency is within expected ranges for your storage configuration
SM21 — System Log The SAP system log captures errors, warnings, and informational messages. After migration, check for:
- Database connection errors
- Communication failures (RFC, HTTP, IDoc)
- Authorization issues from host name changes
- Any error messages not present in the pre-migration baseline
SM37 — Background Job Overview Verify that all scheduled batch jobs are running as expected. Migration often breaks batch job scheduling if host names or system connections changed.
SMGW — Gateway Monitor Check that the SAP Gateway is properly configured and that all registered server programs (RFC destinations) are connected.
2. Performance baseline comparison
This is where your pre-migration Early Watch Alerts pay off. Create a side-by-side comparison:
- Dialog response times (ST03N) — Should be equal or faster on Azure
- Database request times — HANA typically delivers significant improvement over Oracle or SQL Server
- Batch job runtimes — Run the same batch jobs and compare elapsed time
- Report execution times — Execute key reports and compare with baseline timings
- SAPS throughput — Verify the Azure VM delivers the expected SAPS capacity
Exam tip: What if performance is worse?
If post-migration performance is worse than the baseline, common causes include: undersized VM (wrong SAPS capacity), misconfigured storage (wrong disk type or missing Write Accelerator for HANA logs), network configuration issues (accelerated networking not enabled), or HANA memory pressure (database larger than expected after conversion). The exam may present a performance degradation scenario and ask you to identify the root cause.
3. Integration and interface testing
SAP systems rarely operate in isolation. After migration, verify every external touchpoint:
- RFC destinations — Test all RFC connections from SM59. Update any that reference the old host name or IP.
- IDoc interfaces — Send test IDocs to and from connected systems
- Web services and APIs — Verify all SOAP and REST endpoints resolve correctly
- Printer configurations — Often overlooked, always broken after host name changes
- Email (SCOT) — Verify SMTP configuration and send test emails
- File interfaces — Check that batch file transfers to/from shared storage are working
🏗️ Raj grimaces. “We have 47 RFC destinations. Testing every single one sounds painful.”
☁️ Mei is firm. “Test every single one. The one you skip will be the one that fails on Monday morning when payroll runs.”
Azure-specific post-migration steps
Beyond SAP-level validation, there are Azure platform configurations to complete:
Azure VM extension for SAP solutions
The Azure VM extension for SAP (previously called the Enhanced Monitoring extension) collects infrastructure metrics from the Azure VM and makes them available to SAP transaction ST06 and SAP Host Agent. Without this extension, SAP cannot see Azure-level metrics like disk latency, network throughput, or storage IOPS.
Install it immediately after migration. It is a requirement for SAP support — if you open an SAP support ticket for a system running on Azure without this extension, SAP will ask you to install it before investigating further.
Azure backup configuration
Configure Azure Backup for your SAP VMs:
- HANA backup integration — Azure Backup supports native HANA backup streams using Backint. Configure backup policies for log backups (every 15 minutes typical) and full backups (daily).
- VM-level backup — For non-database VMs (application servers, ASCS), configure Azure VM backup for crash-consistent recovery.
- Test the restore — Do not just configure backup. Perform a test restore to verify the backup actually works.
Networking finalization
- Accelerated Networking — Verify it is enabled on all SAP VM network interfaces. This is critical for storage-intensive HANA workloads.
- Proximity Placement Groups — Ensure application and database VMs are in the same proximity placement group to minimize network latency between tiers.
- Network Security Groups — Verify NSG rules allow all required SAP traffic (RFC, HTTP, HANA ports, ICM) while blocking unnecessary access.
- Azure Load Balancer — If using HA configurations, verify the load balancer health probes are detecting the SAP instances correctly.
Exam tip: Backint for HANA backup
Azure Backup uses SAP’s Backint interface for HANA backup integration. Backint is SAP’s standardized API for third-party backup tools to integrate with HANA. The exam may ask how Azure Backup communicates with HANA — the answer is Backint, not filesystem-level snapshots (though Azure also supports storage snapshots for complementary backup strategies).
HLI to Azure VM migration
HANA Large Instances (HLI) were Azure’s original solution for very large HANA databases before Mv2-series VMs existed. HLI was retired on December 31, 2025, and any remaining HLI customers must migrate to Azure VMs. As VM memory capacity has grown (Mv2 to ~12 TB, Msv3/Mdsv3 even higher), the migration path from HLI to VMs is well-established.
Why migrate from HLI to VMs?
Since HLI is now retired, migration is mandatory. The benefits of moving to Azure VMs include:
- Better Azure integration — VMs have native VNet integration, NSGs, Azure Monitor, and all Azure services. HLI connects through a dedicated ExpressRoute circuit with limited integration.
- More flexibility — VMs can be resized, stopped, and moved. HLI is fixed hardware.
- Cost optimization — VM pricing is more granular, and you can use reserved instances and dev/test pricing.
- Simplified networking — No more dedicated ExpressRoute circuit for the HLI connection.
HLI to VM migration workflow
The migration from HLI to Azure VMs uses the same HSR technique you learned in Module 6:
- Deploy the target Azure VM — Mv2-series, Msv3/Mdsv3-series, or M-series with sufficient memory for the HANA database
- Configure HSR from the HLI primary to the Azure VM secondary (ASYNC mode since the HLI and VM are in different network segments)
- Allow initial sync to complete and verify continuous replication
- Plan the cutover — Same process as on-premises to Azure: stop application, wait for log replay, takeover, reconfigure, start
- Decommission the HLI — After validation, return the HLI hardware to Microsoft
☁️ Mei draws the parallel. “The beauty is that this is exactly the same HSR migration pattern you already learned. The only difference is the source is HLI instead of on-premises, but the technique is identical.”
HLI networking detail
HLI connects to your Azure VNet through a dedicated ExpressRoute circuit (separate from your on-premises ExpressRoute). When setting up HSR from HLI to an Azure VM, the replication traffic flows through this ExpressRoute circuit. Ensure the circuit has sufficient bandwidth for the initial full copy and ongoing log shipping — the same network considerations as on-premises to Azure HSR.
Knowledge check
After migrating PrecisionSteel's SAP system to Azure, Raj notices that SAP transaction ST06 shows no Azure infrastructure metrics. What is the most likely cause?
Which SAP transaction code should Raj use FIRST to check for errors immediately after the migration cutover?
Raj is advising an organization that wants to migrate their SAP HANA database from HANA Large Instances (HLI) to an Azure Mv2-series VM. Which migration technique is recommended?
Summary
Post-migration validation is the final gate before declaring success. Use SAP transaction codes (ST03N for performance, SM21 for errors, ST06 for OS health) to verify system health, compare against Early Watch baselines, and test every integration point. On the Azure side, install the VM extension for SAP, configure backups with Backint integration, and finalize networking (accelerated networking, proximity placement groups, NSGs). For HLI-to-VM migrations, the same HSR technique used for on-premises migration applies.
Congratulations — you have completed Domain 1: Migrate SAP Workloads to Azure. You now understand the full lifecycle from assessment through strategy, execution, and validation. Domain 2 will dive into designing and implementing the Azure infrastructure that supports these SAP workloads.
🎬 Video coming soon