Brownfield System Conversion
Convert your existing ECC system to S/4HANA in-place, preserving your configuration, customisations, and historical data while upgrading to the new platform.
months typical duration
business disruption
history preserved
technical complexity
What is a System Conversion?
A brownfield system conversion—also called an in-place conversion or technical upgrade—transforms your existing ECC system into S/4HANA. Your database is converted to HANA, your repository is upgraded to S/4HANA, and your data migrates with you.
This approach preserves your configuration, your customisations, and your historical data. Business processes remain largely unchanged, which means lower change management effort but also carries forward any technical debt from your current system.
The conversion is technically complex—particularly the custom code remediation required to address simplification items and HANA compatibility. But for organisations that want to preserve their investment in processes and history, it's often the most pragmatic path.
Key Characteristics
- Same system, upgraded
- Full data preserved
- Processes unchanged
- Custom code remediation required
Last Updated
January 15, 2026
Sources
- •SAP System Conversion Guide
- •SAP Simplification List
Information based on publicly available SAP documentation and industry sources. For the latest details, consult SAP official materials or qualified partners.
Technical Prerequisites
Mandatory Requirements
SAP ECC Enhancement Pack 7 or 8
Lower EhPs require upgrade first
Unicode System
Non-Unicode systems must convert first
SAP HANA Database
Migrate to HANA before or during conversion
SUM Tool Compatibility
Software Update Manager must support your source release
Pre-Conversion Steps
- 01
Run SAP Readiness Check
Identify simplification items and custom code impacts
- 02
Custom Code Analysis (ATC)
Assess all Z* code for S/4HANA compatibility
- 03
Add-on Compatibility Check
Verify all third-party add-ons have S/4HANA versions
- 04
Sandbox Conversion
Test the conversion on a copy of production first
When Brownfield Fits
Good Fit Indicators
- 1
Process stability is valued
Business wants minimal disruption to how they work
- 2
Historical data requirements
Regulatory or operational need to keep full transaction history
- 3
Manageable custom code
Custom code footprint is assessable and remediable in timeline
- 4
Technical prerequisites met
EhP7+, Unicode, HANA-ready or already on HANA
- 5
Faster timeline preferred
Need to be on S/4HANA sooner than greenfield allows
Warning Signs
- !
Transformation mandate
Business wants to fundamentally change processes—brownfield preserves status quo
- !
Extreme custom code complexity
Thousands of Z objects with deep dependencies may make remediation prohibitive
- !
Heavy add-on landscape
Many third-party products that don't have S/4HANA versions yet
- !
Multi-system consolidation
Need to merge multiple ECC systems—greenfield better suited
Required Workstreams
Custom Code Remediation
Analyse, fix, or retire Z* code to address simplification items and HANA syntax.
Add-on Migration
Upgrade or replace third-party products with S/4HANA-compatible versions.
Technical Preparation
Database migration to HANA, system sizing, infrastructure provisioning.
Conversion Execution
Run SUM for technical conversion, downtime planning, cutover execution.
Integration Adjustment
Update interfaces affected by data model changes and deprecated functionality.
Testing
Regression testing of business processes, custom code, integrations.
Fiori Enablement
Activate and configure Fiori apps for the new user experience (optional but recommended).
Data Archiving
Reduce database size to shorten conversion time and reduce costs.
Change Management
Lighter than greenfield but still needed for UI changes and any process adjustments.
Custom Code: The Critical Workstream
Custom code remediation often determines brownfield timeline and risk
What Makes Code Incompatible
Simplification Items
SAP removed or changed functionality—your code may reference deprecated objects
HANA Syntax
Native SQL or database-specific operations need updating
Data Model Changes
New data models (e.g., Universal Journal) replace old table structures
Business Partner
Customer/Vendor master tables replaced by Business Partner
Remediation Approach
- 1
Inventory
Identify all custom objects using SAP Readiness Check and ATC
- 2
Classify
Categorise by: still needed vs. retire, complexity, business criticality
- 3
Remediate
Fix code, adapt to new data models, or retire and replace
- 4
Test
Regression test every change—automate where possible
Tip: Start custom code analysis early—ideally 6-12 months before planned conversion. This is the workstream most likely to cause delays if underestimated.
Typical Timeline
Assessment & Planning
2-3 monthsPreparation
3-6 monthsConversion (QA)
1-2 monthsFinal Preparation
1-2 monthsProduction Conversion
1-4 daysHypercare
1-2 monthsNote: Custom code volume is the biggest variable. Organisations with minimal customisation can complete in 12 months; heavily customised systems may need 24+ months.