Stage 2 of 5

Pre-Migration Health Check

Before the SI plan locks, surface the operational risks that will become change orders, delays, or cutover issues later. Allari® runs an independent health check on ECC production, custom code, integrations, and team capacity before blueprinting starts consuming the calendar.

The selection is made. The contract is signed and the migration timeline has been communicated to the organization. But your ECC environment is still accumulating transport backlogs, deferred security patches, and undocumented procedures. Stage 2 is the 60–90 day window to ring-fence production before the migration clock starts consuming your team's attention.

The 60–90 days before SI blueprinting is the last cheap window to address operational debt. After the SI engagement begins, every change to ECC production must be evaluated for migration impact. The time available for operational improvements approaches zero by month three of the active build. What doesn't get fixed now won't get fixed — it will become a liability during mock migration cycles, cutover weekends, and data extraction runs.

The health check exists to surface the risks that are invisible in the SOW but expensive during execution: custom code and ATC findings, the integration landscape, Basis and firefighting load, data quality, security, and ECC production ring-fence governance. The deliverable tells leadership what is ready, what is not ready, and what must be fixed before SI blueprinting begins.

Recognition Pattern

You're here if…

• The SI contract is signed and the migration timeline has been communicated to the organization — blueprinting kicks off in 60–90 days.
• Your ECC production environment has accumulated technical debt: deferred kernel upgrades, unapplied security note chains, transport backlog in the import queues, batch scheduling conflicts.
• The transport pipeline is unstable — transports promoted out of sequence have created production inconsistencies that generate intermittent errors no one can reliably reproduce.
• Your internal Basis team is about to be split between keeping ECC running and supporting S/4HANA landscape setup — they cannot do both well.
• Data hygiene has not started: master data governance is informal, archiving has been deferred, and the data remediation scope identified in Stage 1 has not been addressed.
• Integration documentation is incomplete: the interface inventory exists but operational dependencies, failover procedures, and monitoring configurations are not documented.
• Nobody has created an environment-specific runbook: undocumented operational knowledge about SAP® landscape operations exists in people's heads, not in any document the migration team can reference.
• The SI assumes ECC will be stable during the migration. Your ECC team knows it's held together by familiarity, not by process.

Risk Assessment

What's at risk

The SI engagement begins with an assumption: the legacy ECC environment will remain stable and available throughout the 18–36 month migration period.

What the SI contract does not include:

• ECC production stability
• ECC Basis resources in the staffing model
• handling ECC production incidents that disrupt migration workshops, pull team members out of UAT, or cause data extraction failures during mock cycles

If ECC is not stable when the migration starts, it will not become stable during the migration. The core team's capacity will only decrease from this point forward — every week, more attention shifts to S/4HANA design workshops, data validation, integration testing, and organizational change management.

The time available for ECC operational improvements approaches zero by month three of the migration. Deferred security patches create vulnerability exposure that auditors will flag during the migration, and remediation during an active migration is orders of magnitude more complex than remediation before it starts.

The 60–90 day pre-migration window is the last opportunity to address these issues at low cost and low risk. After the SI engagement begins, every change to ECC production must be evaluated for migration impact. The window of freedom narrows to zero.

What is invisible in the SOW but expensive during execution:

• Custom code volume and ATC findings the SI estimate has not yet absorbed
• Integration landscape — iDoc, RFC, BAPI, PI/PO, and point-to-point dependencies that aren't in the interface inventory
• Basis and firefighting load consuming the same team the SI assumes is available for design and UAT
• Data quality across master data, GR/IR, and historical volumes that will not survive extraction without remediation
• Security, SoD, and access control exposure during a multi-system dual-run
• ECC production ring-fence governance — what is permitted to change, what is frozen, who arbitrates
• Unclear ownership between the SI, the client, and IT operations once execution starts

Allari does not replace your SI and does not run the migration build. We sit on the client side of the operating model: keeping ECC stable, making operational risk visible, protecting internal capacity, and helping leadership govern the transition before, during, and after migration.

What We Deliver

60–90 Day Health Check

Custom Code Inventory & ATC Analysis

Complete catalog of all custom objects in the ECC landscape: Z/Y programs, function modules, enhancements (user exits, BADIs, enhancement spots), custom tables, custom transactions. Each object classified by usage frequency (active, dormant, dead), S/4HANA compatibility status (compatible, requires remediation, deprecated), and business criticality. ATC analysis executed against the S/4HANA simplification database with findings categorized by severity and remediation effort.

Integration Landscape Mapping

Every active interface documented: source system, target system, protocol (iDoc, RFC, BAPI, flat file, API), data volume, frequency, business process dependency, and S/4HANA compatibility status. Integration architecture diagram produced. Each interface classified by migration impact: no change required, configuration change, redesign required, retirement recommended.

Data Volume & Quality Audit

Table-level data volume analysis across all clients. Identification of archiving candidates (IDOC, BDOC, change documents, application logs, spool). Master data quality assessment: vendor, customer/Business Partner, material, GL account, cost center — duplicates, inconsistencies, orphaned records. Data migration readiness score by migration object.

Organizational Capacity Assessment

How many people does the internal SAP team have? What are they doing today? How much of their capacity is consumed by run-state operations? How much would be required for migration support — design workshops, UAT, data validation, integration testing? Can the organization staff both workstreams simultaneously, or does it need structural separation? Output: the reactive-to-strategic ratio for the core team, measured against current production load.

ECC Production Ring-Fence & Code Freeze Governance

Establish a controlled change management process for the ECC production environment: what changes are permitted, what requires approval, what is frozen. Transport governance tightened — every transport evaluated for production stability impact before import. The goal is a predictable, stable ECC environment that the SI can rely on for data extraction and mock migration cycles.

Basis Firefighting Absorption

Every reactive Basis task — failed batch jobs, performance alerts, transport conflicts, user issues, security incidents — absorbed by the Allari team. The internal Basis team's capacity is freed for migration preparation activities. This is not a gradual transition; the pre-migration window requires immediate operational capacity to absorb the reactive load.

Transport Pipeline Stabilization

Complete review and remediation of the STMS transport pipeline. Out-of-sequence transports identified and resolved. Import queue backlogs cleared. Transport procedures documented and enforced. The transport pipeline must be clean before the migration starts — every production inconsistency that exists when the SI begins data extraction becomes a data quality issue in S/4HANA.

Pre-Cutover Data Hygiene

Archiving of historical data: IDOCs, BDOCs, change documents, application logs, spool data — reducing the data volume that must be migrated and improving extraction performance. Master data cleanup initiated: vendor deduplication, material master normalization, Business Partner cleanup, GR/IR clearing account reconciliation.

Integration Documentation & Validation

Every active interface tested end-to-end and documented: source, target, protocol, data volume, business process dependency, monitoring configuration, failover procedure. Interfaces operating on undocumented knowledge are formalized. The integration documentation becomes the SI's reference for designing the S/4HANA integration architecture.

Environment-Specific Runbook Creation via Dynamic Runbook

Complete operational runbook for the ECC landscape: every batch schedule, every monitoring procedure, every vendor escalation path, every workaround, every custom configuration. This is the institutional knowledge capture that ensures ECC operations continue uninterrupted regardless of who is doing them.

Health Check Scorecard with Risk Register

A single document consolidating custom code, integration, data, operational, and organizational findings into a scored assessment. Risk register with likelihood, impact, and mitigation for each identified risk. Remediation plan with specific findings, risk ratings, and the items that must be addressed before blueprinting kicks off. The scorecard, risk register, and remediation plan belong to the client — usable with any SI or core team.

Engagement Structure

How it works

Phase 1 — Days 1–15: Emergency Stabilization

Highest-priority items addressed first: critical security patches applied, transport backlog cleared, failing batch jobs root-caused and resolved. Allari team embedded alongside internal Basis team in shadow mode for the first week, then beginning to absorb the reactive queue.

Phase 2 — Days 16–45: Systematic Remediation

Transport governance process established and enforced. Archiving programs initiated. Integration documentation campaign executed. Dynamic Runbook capture progressing through all operational domains. Ring-fence governance implemented.

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

ECC environment at documented, stable baseline. All operational procedures in the Dynamic Runbook. Core team capacity freed for migration activities. Pre-migration data hygiene complete. The SI receives a stable, documented, predictable ECC environment — not the fragile, undocumented one that existed 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

40–60%

Typically Unused Custom Code

55–75%

Of Migrations Exceed Budget

Specific engagements

Named Client Evidence

Global advanced-materials manufacturer

The global advanced-materials manufacturer's 5-year JD Edwards®-to-SAP migration was led by IBM as the SI. Allari did not perform the SAP implementation — we held the JDE legacy run and protected the internal build team's capacity. That work required a stable, documented legacy environment from day one. The pre-migration health check — operational runbook creation, process documentation, knowledge capture — is what enabled the 25 FTE-equivalent redeployment from JDE Run to SAP build over five years with zero escalations to the build team. The health check investment compounds throughout the entire migration period.

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, surface the operating risk.

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-minute working session: we identify the operational debt that will surface in cutover and propose what to fix first.

30 minutes. No pitch. No obligation.