S/4HANA Technical Migration: Don’t Let Downtime and Code Surprises Sink Your Project

Li Wei breaks down what you need to know

I was called into a project last month where the cutover window had been planned for 48 hours. The actual business downtime was over 90. The root cause wasn’t exotic—it was a patchwork of custom ABAP nobody had touched since the ECC days, combined with a 4 TB table the team thought they could migrate on the fly. Don’t let this be your story.

After nine years of leading migrations—first inside Alibaba, then at multinational consultancies, and now as an independent architect—I’ve seen the same expensive patterns repeat. The hype around tools like SAP Migration Cockpit often masks the gritty, unglamorous reality: most migration pain comes from custom code, data volume, and wishful thinking about downtime. Here’s how to cut through the noise and get your technical migration on solid ground.

The Real Story: Why Technical Migrations Go Off the Rails

SAP sells S/4HANA as a new engine that simplifies your landscape. What they don’t emphasize enough is how many hidden dependencies your current system carries. A brownfield (system conversion) migration surfaces decades of accumulated custom objects, obsolete user exits, and direct table reads that no longer work against the simplified data model.

A mid-size manufacturer I worked with recently discovered almost 40% of their custom objects broke in their first dry-run. Why? Their ABAP code was riddled with direct reads on BKPF and BSEG — tables that are replaced by the compatibility views but don’t perform the same way under the hood. Without early ABAP remediation, those functional gaps would have paralyzed order-to-cash post go-live. The team spent four extra sprints fixing code that should have been addressed before the migration project even kicked off.

Data volume is the other silent killer. I’ve seen clients assume that HANA’s in-memory speed will magically reduce downtime. It won’t. If you’re moving 2 TB of transactional data, the migration processes—dump, export, import, conversion—still run at I/O-bound speeds. Unless you archive or partition aggressively, your cutover weekend bleeds into Monday morning chaos.

What This Means for You: Five Critical Areas to Address

Practitioners across architects, basis, and functional roles need to internalize five non-negotiable checkpoints:

1. Custom code remediation must start yesterday.
   Running the SAP Readiness Check gives you a high-level view of impacted objects, but it’s not a replacement for a thorough ATC (ABAP Test Cockpit) analysis with S/4HANA-specific checks. Look for direct table access to now-obsolete tables, missing HANA-optimized OpenSQL, and ABAP code that relies on old BAPIs that have been simplified. Expect to invest at least two full sprints purely on remediation—even before the first sandbox conversion.

2. Data volume determines your downtime ceiling.
   Identify the largest tables (likely ACDOCA, MATDOC, MSEG equivalents) and explore archiving options during the pre-migration phase. One retail client we helped cut their overall migration time from 55 to 22 hours simply by moving three years of line items to cold storage before the technical conversion. Every terabyte you remove is a direct reduction in cutover risk.

3. Dry-run testing isn’t optional; it’s the only way to get a realistic downtime estimate.
   SAP’s Migration Cock

References

• What are the challenges of SAP S/4HANA migration
• SAP HANA Platform Overview- ABAP Development Guide

References

• ABAP Development Guide
• SAP HANA Platform Overview
• What are the challenges of SAP S/4HANA migration