Pre-Migration Health Check: SAP ECC → S/4HANA

Stage 2 of 5

Find the problems before the SI plan is locked, while they are still cheap to fix. Allari® checks ECC, custom code, integrations, and team capacity before blueprinting starts.

The contract is signed, but ECC still has transport backlogs, missed patches, and undocumented procedures. The 60–90 days before blueprinting is your last cheap chance to fix them. After that, every ECC change must be checked against the migration, and by month three there's no time left.

We look at custom code and ATC findings, integrations, Basis firefighting, data quality, security, and change rules for ECC, and tell leadership what is ready, what is not, and what to fix before SI blueprinting starts.

Recognition Pattern

You're here if…

• The SI contract is signed and blueprinting starts in 60–90 days.
• ECC has a backlog: deferred kernel upgrades, unapplied security notes, stuck transports, batch conflicts.
• Out-of-order transports cause random errors nobody can reproduce.
• Your Basis team is about to be split between ECC and S/4HANA setup — they can't do both well.
• Data cleanup and archiving haven't started.
• Interfaces are listed, but dependencies, failover, and monitoring aren't documented.
• How SAP® really runs lives in people's heads, not in a runbook.
• The SI assumes ECC will be stable. Your team knows it's held together by habit, not process.

Risk Assessment

What's at risk

The SI assumes ECC will stay stable for the whole 18–36 month migration. But the SI contract does not include:

• ECC production stability
• ECC Basis resources in the staffing model
• ECC incidents that disrupt workshops, pull people out of testing, or break data extraction

If ECC isn't stable when the migration starts, it won't get stable during it. Your team will only get busier, and missed patches that auditors flag mid-migration are far harder to fix.

The real risks are the ones the SI contract doesn't mention:

• Custom code and ATC findings not yet in the SI estimate
• Integrations — iDoc, RFC, BAPI, PI/PO links missing from the inventory
• Basis firefighting taking the people the SI expects in design and testing
• Data quality in master data, GR/IR, and old records that needs cleanup first
• Security and SoD gaps while two systems run
• Change rules for ECC — what can change, what is frozen, who decides
• Unclear ownership between the SI, your company, and IT

Allari does not replace your SI or build the new system. We work for you: keeping ECC stable, showing risks early, and protecting your team's time before, during, and after the migration.

What We Deliver

Custom Code Inventory & ATC Analysis

A list of every custom object — Z/Y programs, enhancements, BADIs, tables, transactions — rated by use, S/4HANA compatibility, and business importance. ATC is run against the S/4HANA simplification database, with findings ranked by effort.

Integration Landscape Mapping

Every interface documented — systems, protocol (iDoc, RFC, BAPI, file, API), volume, and S/4HANA impact: keep, reconfigure, redesign, or retire.

Data Volume & Quality Audit

Data volumes, archiving candidates (IDOC, BDOC, logs, spool), and master data quality — duplicates and errors in vendors, customers, materials, and GL accounts. Each data object gets a readiness score.

Organizational Capacity Assessment

How much of your SAP team's time goes to day-to-day support, and how much the migration will need. Can you staff both, or do you need a separate support team?

ECC Production Ring-Fence & Code Freeze Governance

Clear rules for what can change in ECC, what needs approval, and what is frozen — so the SI gets a stable system for data extraction and test migrations.

Basis Firefighting Absorption

Allari takes on Basis tickets right away — failed jobs, alerts, transport conflicts, security — so your Basis team can prepare for the migration.

Transport Pipeline Stabilization

Out-of-order transports fixed, backlogs cleared, procedures written down. Any mess left in ECC becomes a data problem in S/4HANA.

Pre-Cutover Data Hygiene

Archive old data to shrink what must be migrated. Start master data cleanup: duplicate vendors, material master, Business Partner, and GR/IR.

Integration Documentation & Validation

Every interface tested end-to-end and written up, including monitoring and failover. The SI uses it to design S/4HANA integrations.

Environment-Specific Runbook Creation via Dynamic Runbook

A full ECC runbook — batch schedules, monitoring, vendor contacts, workarounds — so support continues no matter who does it.

Health Check Scorecard with Risk Register

One scored document covering code, integrations, data, support, and team. A risk list with fixes, and what must be done before blueprinting. You own it and can use it with any SI.

Engagement Structure

How it works

Phase 1 — Days 1–15: Emergency Stabilization

Urgent items first: critical patches, transport backlog, failing batch jobs. Our team works alongside your Basis team for a week, then starts taking tickets.

Phase 2 — Days 16–45: Systematic Remediation

Transport rules in place. Archiving started. Integrations documented. Runbook growing. ECC change rules in force.

Phase 3 — Days 46–90: Migration-Ready Handoff

ECC is stable and documented, data cleanup is done, and your team is free for the migration. The SI gets a predictable ECC, not the fragile one from 90 days ago.

Stage 2

Evidence

Third-party research

Market Context

Industry data on the ECC environments most organizations bring into a migration:

22,000

Avg Custom Objects Per ECC System

2.7M

Lines of ABAP Code

Typically Unused Custom Code

Of Migrations Exceed Budget

Specific engagements

Named Client Evidence

Global advanced-materials manufacturer

Deep Dive

Related resources

Stage 2 → Stage 3 · SAP ECC Lifecycle

Where this goes next

Once readiness risk is visible, the next move is protecting the run. Move to ECC Operations During Migration before production work pulls your S/4HANA build team backward.

SAP ECC - STAGE 2 PRE-MIGRATION STABILIZATION

Before the SI plan locks, find the risks.

Cutover is the worst possible moment to discover broken IDocs, undocumented BAPIs, or batch dependencies no one owns.

Stabilize ECC before the migration starts.

30 minutes. No pitch. No obligation.