System Conversion Execution: Custom Code Remediation, Downtime, and Cutover Risk

Explanation

System conversion (also called brownfield conversion) takes an existing ECC system and technically transforms it into S/4HANA while preserving configuration, custom code, and historical data. Architects and senior consultants need to understand this path in enough technical depth to plan realistic timelines, staff the right skills, and set expectations with the business about risk and downtime — because this is usually the single largest source of schedule slippage in a transformation program. The technical conversion itself is performed using SAP's supported tooling that combines a database migration (if moving from a non-HANA database) with the software update to the S/4HANA code line, followed by execution of conversion-relevant activities such as simplification item checks. Simplification items describe functional areas where S/4HANA data structures, business logic, or table design differ from ECC (for example, changes in finance line-item tables, business partner consolidation of customer/vendor master data, and material number length extensions). Before conversion, a mandatory readiness check evaluates which simplification items apply to the system based on active configuration and data, and produces a list of pre-checks and post-activities that must be completed. Custom code remediation is usually the most underestimated workstream. Every custom ABAP object that touches now-changed tables, obsolete function modules, or removed data elements must be analyzed. Static analysis tooling can flag syntax and reference issues, but it does not tell you whether the business logic is still correct — for example, code that assumed separate customer and vendor tables now needs to work with the unified business partner model, which is a semantic change, not just a technical one. A remediation project should classify findings into: must-fix-before-go-live (syntax errors, hard runtime failures), functionally-broken-but-compiles (logic errors that only surface in testing), and safe-to-defer (dead code, rarely used reports). Underestimating the second category is the most common cause of post-go-live defects. Downtime planning matters because most system conversions are executed as a single cutover event with the production system unavailable to users. The downtime includes the technical conversion steps, any near-zero-downtime tooling optimizations if used, data consistency checks, and business validation before the system is reopened. Architects should insist on at least one full technical rehearsal in a production-sized sandbox before the actual cutover, because conversion duration is highly dependent on data volume, and only a realistic rehearsal reveals whether the downtime window is achievable. If a rehearsal shows the downtime exceeding the agreed business window, options include data volume reduction (archiving before conversion), phased conversion of company codes if the landscape allows it, or acceptance of a longer window with business sign-off — these are architecture decisions, not just Basis tasks. Rollback planning for a conversion is different from a new implementation rollback: because the conversion is in-place, the primary rollback mechanism is typically restoring the pre-conversion database backup and reopening the original ECC system, which means the go/no-go decision points and backup validation must be explicitly rehearsed, and any transactions processed during a failed cutover attempt must be identified and manually reconciled. Cloud-hosted landscapes (private cloud) may offer snapshot-based rollback with different timing characteristics than on-premise storage-level backups, so the actual rollback SLA should be validated with the hosting/infrastructure team rather than assumed. Public cloud S/4HANA does not use this conversion path at all — it is a new implementation with configuration and data migration through supported cloud tooling, so system conversion knowledge does not transfer directly to public cloud projects, only conceptually (the need to remediate custom logic still exists, but as intelligent extensions built on cloud-compatible frameworks instead of code remediation in place).

Code example

* Illustrative only: pattern for flagging business-partner-affected custom code* during remediation review (not a real transaction or API name) REPORT z_custom_customer_report. * ECC-style logic before remediation review:* SELECT kunnr, name1 FROM kna1 INTO TABLE lt_customers WHERE ... * Remediation note for reviewer:* - KNA1 remains available via compatibility views in many S/4HANA releases,*   but new development must use the business partner model instead.* - Confirm with the current release's simplification guidance whether*   the compatibility view is still supported before assuming this works unchanged.* - Flag this object as 'functionally-broken-but-compiles' until validated*   against business partner data in a converted sandbox. DATA: lt_customers TYPE TABLE OF kna1.* SELECT statement retained for illustration; validate against your* actual release's data model before treating this as safe.SELECT kunnr name1 FROM kna1 INTO TABLE lt_customers. 

Real project scenario

A retail company converted its ECC finance and logistics system to S/4HANA private cloud edition. The initial readiness check reported over 900 custom objects impacted, but the team's static tooling only classified syntax-level errors, missing roughly 60 objects with business-partner-related logic that compiled cleanly but returned incorrect vendor payment terms during integration testing. The issue was caught only during the second conversion rehearsal, three weeks before the planned go-live, forcing a two-week schedule slip to fix and retest the affected payment run logic. The post-project retrospective added a mandatory functional test pass for all business-partner-touching objects as a standing checklist item for future conversions.

Common mistakes

• Treating the automated simplification item readiness check as a complete remediation scope, missing objects with correct syntax but broken business logic • Skipping a full-scale technical conversion rehearsal and discovering downtime overruns only during the actual cutover • Assuming public cloud custom code remediation experience transfers directly to a system conversion project, or vice versa • Not rehearsing the rollback/restore procedure and discovering during a failed cutover that backup restore takes longer than the agreed downtime window • Underestimating business partner and finance data structure changes as 'technical only' when they require functional validation with process owners

Best practices

• Run the readiness check early and repeatedly as configuration and custom code change during the project, not just once at kickoff • Classify remediation findings into severity tiers and assign functional owners to validate business logic changes, not just technical fixes • Execute at least one full-scale technical conversion rehearsal against production-representative data volumes before committing to a go-live date • Define explicit go/no-go criteria and rollback triggers before cutover night, and rehearse the rollback/restore procedure itself • Document which simplification items apply and their functional impact in language business process owners can validate, not just a technical checklist

Interview angle

Interviewers assess whether a candidate understands system conversion as a business-risk exercise, not just a technical upgrade: expect questions on how you scoped custom code remediation, how you validated downtime assumptions with rehearsals, what your rollback trigger criteria were, and how you handled a scenario where testing revealed a remediation gap late in the project. Candidates who can describe a concrete go/no-go decision framework and a real remediation classification approach stand out over those who only describe the tooling.