Overview
SAP S/4HANA is SAP’s next-generation business suite, built entirely on the advanced in-memory SAP HANA platform. It combines a modern, role-based SAP Fiori user experience with simplified processes that eliminate redundancies andreduce data footprints. By unifying functionality, optimizing applications forHANA, and delivering a responsive UX, S/4HANA empowers businesses to runsmarter and simpler in today’s digital economy—enabling seamless integrationwith IoT, Big Data, mobile-first strategies, and business networks. This blog walks you through the structured conversion process to move from SAP ECC on HANA to SAP S/4HANA.
Prepare Phase
The preparation phase of an SAP S/4HANA conversion ensures your existing SAP ERP system, custom code, and landscape are ready before the technical conversion begins. It involves validating system prerequisites, analyzing simplification impacts, managing data volume, and cleaning up or adapting custom code. By addressing risks early—such as incompatible add-ons, business functions, or large datasets—you minimize downtime and create a stable foundation for the realization phase.
Key Steps in the Prepare Phase
- System & Prerequisite Checks – Ensure Unicode compliance, split dual-stack systems, confirm OS/DB compatibility, and decide on Fiori deployment.
- Simplification Item Analysis – Use the Simplification Item Catalog and run the Simplification Item-Check (SI-Check) to detect mandatory adaptations.
- Maintenance Planner – Validate add-ons, industry solutions, and business functions; generate the stack.xml file for SUM.
- Custom Code Preparation – Identify, clean up,and adapt incompatible custom developments using migration tools.
- Data Volume Management (DVM) – Archive and reduce system size to shorten downtime and optimize future performance.
- Cross-Application Preparations – Handle tasks such as uninstalling obsolete apps, removing client 066, preparing authorizations, and setting up Maintenance Planner.
- Application-Specific Preparations – Execute module-level steps (e.g., Finance-specific checks).
- Validation Tools – Optionally use Data Transition Validation (DTV) to compare business data before and after conversion.
Prepare Phase – 1. System & Prerequisite Checks
Before starting a system conversion to SAP S/4HANA, you must ensure that your existing SAP ERP system meets the mandatory technical prerequisites. These checks are critical because failure to meet them will block the conversion process in later stages (SUM will stop if prerequisites aren’t satisfied).
- Unicode Requirement
- The target system must be Unicode. If your source ERP is still non-Unicode, you must first perform a separate Unicode conversion project. SAP does not allow direct conversion of non-Unicode systems to S/4HANA.
- ABAP-Only Systems
- SAP S/4HANA only supports ABAP. If your system is a dual stack (ABAP+ Java), you must split it into separate ABAP and Java stacks using SAP’s split tools before proceeding.
- Operating System (OS) and Database (DB) Compatibility
- Check the SAP Product Availability Matrix (PAM) to ensure your OS and DB versions are supported for the S/4HANA target release.
- In some cases, you may need to first upgrade your database or perform a system copy to a supported environment.
- Java Components Validation
- Some Java components may still be required (e.g., Adobe Document Services, ESR, AEX, Elster, Swift). Others are obsolete in S/4HANA and must be decommissioned.
- Fiori Deployment Decision
- Decide whether to deploy SAP Fiori embedded (on the same S/4system) or as a hub (separate front-end server).
- This decision affects which component levels (Gateway, FES, SAP_UI, ABAP Platform) you must install and prepare.
- Custom Code Prerequisites
- If your ERP system uses custom CDS views or extensions, plan to adapt or rebuild them in the S/4HANA environment.
- System Landscape Setup
- SAP recommends a distributed system landscape (e.g., copy DEV →DEV2) to test conversion in a sandbox before executing on production. This ensures risks are caught early.
Prepare Phase – 2. Simplification Item Analysis
The Simplification Item Analysis is one of the most critical steps in the preparation phase, as it identifies and validates the business and technical changes that will impact on your system when moving to SAP S/4HANA. Simplification items document how functionality has been redesigned, replaced, merged, or deprecated in the new release. Without properly addressing them, the conversion will fail at later stages.
- Simplification Item Catalog
- This is the central reference for all simplification items. It describes the functional changes between SAP ERP and S/4HANA, including simplified processes, merged database tables, removed transactions, and new data models.
- It replaces the older PDF “Simplification List” and provides moreup-to-date, searchable content.
- Simplification Item-Check (SI-Check)
- Executed via transaction /SDF/RC_START_CHECK, this check analyzes your ERP system against the target S/4HANA release.
- It highlights which simplification items are relevant for your system based on active business functions, configuration, and used transactions.
- SI-Check must be run multiple times during the project: early in the preparation phase, after corrections, and later by SUM during conversion.
- Error and Consistency Handling
- SI-Check classifies findings as errors (must be resolved beforeconversion) and warnings (require attention but may not block).
- Errors typically arise from obsolete transactions, data model inconsistencies, or incompatible business functions.
- Application-Specific Guidance
- Each simplification item includes a reference to relevant SAP Notes and required pre-steps. For example, Finance simplifications often require executing reconciliation reports or activating new data structures.
- The check helps pin-point module-specific adaptations (e.g., inLogistics, Manufacturing, or Finance).
- Iteration and Tracking
- The process is iterative: after resolving issues, rerun the SI-Check until all blocking errors are cleared.
- Tracking progress here avoids show stoppers during the Realize Phase when SUM enforces the checks automatically.
Prepare Phase – 3. Maintenance Planner
The Maintenance Planner is a mandatory tool in the preparation phase of an SAP S/4HANA conversion. It validates the technical feasibility of your conversion and generates the essential stack.xml file required by the Software Update Manager (SUM). Without successfully completing this step, the conversion cannot proceed.
- Add-On & Industry Solution Validation
- Maintenance Planner checks whether installed add-ons or industry solutions in your ERP system are compatible with the target S/4HANA release.
- Incompatible or unsupported add-ons must be uninstalled, upgraded, or replaced before conversion.
- Business Function Checks
- Business functions are validated against the new release. Some may be always on, always off, or customers switchable in S/4HANA.
- If a business function in your system is active but marked as always off in the target release, this creates a blocker that must be resolved before conversion.
- Stack.xml Generation
- After passing validation, Maintenance Planner produces the stack.xml file.
- This file contains all the information SUM requires for the conversion, including software components, add-ons, and required patches.
- An S/4HANA license is required to generate the stack.xml.
- System Consistency Validation
- The planner ensures your source system is technically consistent with the target release’s requirements (software versions, kernel patches, and system attributes).
- Integration with SAP Solution Manager
- Maintenance Planner connects with SAP Solution Manager to read your system landscape data and keep it synchronized with SAP’s backend. This ensures that planning is based on accurate system information.
- Iterative Use
- Like the SI-Check, Maintenance Planner should be run early and rerun after changes (e.g., after uninstalling an incompatible add-on).
- This ensures that your final stack.xml is accurate and aligned with the state of the system when SUM is executed.
Prepare Phase – 4. Custom Code Preparation
Custom code is one of the biggest risk factors in any SAP S/4HANA conversion project. Over the years, ECC systems accumulate enhancements, Z-programs, user exits, BAdIs, and modifications that may not be compatible with the simplified data model and technologies in S/4HANA. Preparing custom code early ensures that your critical business processes continue to run after conversion.
- Why It Matters
- SAP S/4HANA removes redundant functionality, merges tables, and introduces CDS-based data models. Custom programs that directly reference old tables, use deprecated transactions, or rely on obsolete functions will break.
- Addressing this after the technical conversion is time-consuming and disruptive. Early analysis gives you a clear remediation plan.
- Custom Code Analysis Tools
- Use the Custom Code Migration (CCM) apps and the ABAP Test Cockpit (ATC) with the S/4HANA readiness checks.
- These tools identify:
- Unused custom objects (safe to decommission).
- Impacted code referencing removed or changed elements.
- Areas where adaptation or redesign is required (e.g., CDS views insteadof old SELECTs).
- Usage and Decommissioning
- Many ECC systems contain 40–60% unused custom code.
- By using usage statistics (e.g., from SCMON or UPL), you can identify which custom objects are executed in production.
- Decommissioning unused code reduces both remediation effort and long-term technical debt.
- Remediation Strategy
- Quick fixes: Adjust SELECT statements, replace obsolete transactions, or update field references.
- Redesigns: Where functions are eliminated or replaced with new frameworks (e.g., output management, credit management, FI/CO changes).
- Rebuilds: In cases where simplification requires adopting new technologies (CDSviews, Fiori apps, OData services).
- Transport Strategy
- Run custom code checks in a sandbox or DEV2 system.
- Package corrections into transport’s that can be re-applied after the production conversion. This minimizes downtime and reduces rework.
- Collaboration with Business & Developers
- Engage functional teams to validate whether some custom developments are still needed. Many “temporary” customizations can be retired when equivalent S/4HANA standard functionality exists.
Prepare Ph – 5. Data Volume Management (DVM)
Data Volume Management (DVM) is a crucial step in preparing for an SAP S/4HANA conversion. Over time, ECC systems accumulate large amounts of historical and redundant data, which can significantly impact conversion runtime, system downtime, and even the cost of the infrastructure. By proactively reducing data volume, companies can ensure a faster, leaner, andmore efficient migration.
- Why It Matters
- Large databases directly increase the runtime of SUM (Software Update Manager) during conversion.
- A smaller database size not only reduces downtime but also lowers the hardware requirements for SAP HANA.
- Managing data volume before conversion helps maintain performance and keeps future operational costs under control.
- DVM Tools
- SAP provides Data Volume Management tools (part of the Solution Manager and SAP’s DVM services) to analyze data distribution and identify cleanup opportunities.
- These tools simulate how much space can be saved through compression, reorganization, and archiving.
- Key Activities
- Housekeeping – Delete temporary, obsolete, or application logs (e.g., old IDocs,workflow logs, or change documents).
- Archiving – Move historical but legally relevant data into external storage while keeping it accessible for reporting.
- Compression & Reorganization – Apply HANA-specific compression and reorganize tables to optimize space.
- Master Data Cleansing – Eliminate duplicates and inactive master data records (e.g., vendors,customers).
- Forecasting Future Growth
- DVM tools also project future database growth based on current usage.This helps design the right-sized HANA environment and prevents overspending on hardware.
- Timing Considerations
- Start DVM activities well before the technical conversion project.
- Archiving projects require business involvement for data retention policies and legal compliance.
- Benefits Beyond Conversion
- Reduces conversion runtime and downtime.
- Improves system stability and performance after migration.
- Optimizes long-term TCO (total cost of ownership) by reducing infrastructure needs.
Prepare Phase – 6. Cross-Application Preparations
Cross-application preparations are activities that impact the system, rather than a specific module or function. These steps ensure that all layersof the ERP system are aligned with SAP S/4HANA’s requirements and that no technical inconsistencies remain that could block the conversion. They are often mandatory housekeeping tasks and adjustments that must be executed beforethe SUM runs.
- Why It Matters
- Even if your system passes the technical checks, inconsistencies at the cross-application level can cause SUM errors.
- Cleaning up clients, obsolete apps, and authorizations ensures a smooth transition without unnecessary failures.
- Key Activities
- Maintenance Planner Setup
- Ensure the system is properly registered and connected with the Maintenance Planner.
- Update SPAM/SAINT to the required minimum patch level (71 or higher).
- Configure RFC connections between the source system and SAP Solution Manager (if used).
- Client Cleanup
- Delete client 066, which is delivered for early release testing but is not supported in S/4HANA.
- Ensure no obsolete or test clients exist that could conflict during conversion.
- Obsolete Fiori Apps & Add-ons
- Identify and remove deprecated Fiori apps and add-ons that are no longer supported in the S/4HANA release.
- This avoids duplicate functionality or inconsistencies after migration.
- Authorization & Security Preparations
- Review your authorization concepts and roles.
- Prepare to adopt new S/4HANA-specific roles, especially for SAP Fiori.
- Adjust SU24 proposals and check for obsolete authorization objects flagged in SI-Check.
- Output Management & Printing
- Legacy output management mechanisms may need to be adapted to the new S/4HANA Output Management framework (based on BRF+).
- Prepare forms and print processes accordingly.
- Background Jobs & Interfaces
- Review active batch jobs and external interfaces that may reference obsolete transactions or tables.
- Deactivate or adapt them before conversion.
- SAP Notes & References
- SAP provides conversion-specific notes for cross-application preparations, covering technical housekeeping and known errors.
- Running SI-Check early will also highlight cross-ap.
Prepare – 7. Application-Specific Preparations
While cross-application preparations address system-wide readiness, application-specificpreparations focus on individual business modules (such as Finance, Logistics, Manufacturing, or HR) that are directly impacted by simplification items in SAP S/4HANA. Each application area has its own prerequisites and adjustments that must be completed before the technical conversion. These steps are typically derived from the Simplification Item Catalog and validated through the SI-Check results.
- Why It Matters
- Each module may have deep functional and data model changes in S/4HANA (e.g., universal journal in Finance, material ledger in Logistics).
- If these changes are not prepared upfront, the SUM conversion will fail, or critical processes will not function properly post-migration.
- Finance (FI/CO) Preparations
- Finance is the most impacted area in S/4HANA due to the introduction ofthe Universal Journal (table ACDOCA).
- Key pre-steps include:
- Executing reconciliation reports between FI and CO.
- Migrating classic General Ledger or New GL to the S/4HANA-compatible ledger.
- Preparing Asset Accounting (new depreciation areas, charts of depreciation, etc.).
- Following SAP Note 2332030 for detailed finance-specific conversion activities.
- Logistics & Supply Chain Preparations
- Simplifications affect areas like Material Ledger (mandatory activation), Production Planning (PP/DS), and Warehouse Management.
- Ensure configuration consistency, activate required business functions, and prepare migration of master data (e.g., materials, BOMs, routings).
- Sales & Distribution (SD) and Materials Management (MM)
- Check for obsolete transactions and tables flagged in SI-Check.
- Prepare for adaptations in pricing, credit management, and output management (now based on BRF+).
- Review open sales/purchase documents and clean up inconsistencies.
- Human Capital Management (HCM)
- If SAP HCM is in scope, validate compatibility with the S/4HANA release.
- In some cases, SAP recommends a separate HCM system or integration via SAP Success Factors.
- Industry Solutions
- Some industry-specific add-ons (IS-Oil, IS-Retail, etc.) may require patches, replacements, or decommissioning. Maintenance Planner validations will highlight these.
- Custom Developments per Application
- Use SI-Check and custom code analysis to review Z-programs per application area.
- For example, in Finance, custom reports reading from classic FI tables (BSEG, COEP) must be adapted to use CDS views and the Universal Journal.
- Validation with Business Stakeholders
- Functional teams must be engaged to review whether processes can be replaced with standard S/4HANA capabilities.
- This often eliminates legacy work arounds and reduces technical debt.
Prepare Phase – 8. Validation Tools
Validation tools provide assurance that the business data and processes remain correct and consistent after the system conversion. While not mandatory, they are highly recommended to reduce risk and build confidence with both IT and business stakeholders.
- Why It Matters
- A conversion is more than just a technical exercise — the integrity of business-critical data must be preserved.
- Validating before and after migration prevents costly errors in financials, logistics, and reporting.
- Data Transition Validation (DTV)
- DTV is SAP’s tool for comparing business data before and after conversion.
- It allows project teams to define validation scenarios with reports or transactions relevant to their business processes (e.g., financial balances,open purchase orders).
- After the upgrade, the same reports are run and compared against pre-conversion results to verify correctness.
- Usage Process
- Define Reports – Agree with business and audit teams on which reports/transactions to validate.
- Set Up DTV Project – Configure test cases in the tool and assign responsible teams.
- Extract Source Data – During system ramp-down, extract data from the legacy ERP system.
- Validate Post-Conversion Data – After conversion, run the same reports inthe S/4HANA environment and compare results.
- Integration with Governance
- Results can be shared with internal and external auditors to demonstrate compliance and correctness.
- This adds assurance that the migration meets regulatory and audit requirements (e.g., for Finance).
- Additional Validation Options
- Beyond DTV, companies often run business process test scripts in key modules (FI, SD, MM, PP).
- Automated testing tools (e.g., CBTA in Solution Manager or third-party tools) can also be integrated into this validation step.
Realize Phase
Realize – 1. Software Update Manager (SUM)
The Software Update Manager (SUM) is the central tool that executes technical conversion. After all prerequisites from the preparation phase are complete, SUM handles the heavy lifting: database migration (if needed), the actual software update, and the data conversion into S/4HANA structures.
- Core Functions
- Performs the upgrade of the ERP system to S/4HANA.
- Migrate the database to SAP HANA if the source system is running on a non-HANA database.
- Converts application data to the new S/4HANA data model.
- Key Considerations
- Requires the stack.xml generated in Maintenance Planner.
- Executes its own run of the Simplification Item-Check (SI-Check)and will not proceed if unresolved errors remain.
- Runtime depends on system size, hardware, and data volume (hence the importance of DVM).
- Downtime
- SUM introduces technical downtime, as the system is unavailable during migration. Downtime optimization options (like nZDT or downtime-minimized SUM)are available for critical systems.
Outcome:
After SUM execution, the system is technically on S/4HANA and ready for further adaptations and validation.
Realize Phase – 2. Silent Data Migration (SDMI)
In classical upgrades, most application data migration happens during downtime. With S/4HANA, SAP introduced the Silent Data Migration Infrastructure (SDMI) to reduce downtime.
- How It Works
- Moves selected application data in the background after the upgrade,while the system is already up and running.
- Business operations can continue while remaining data adjustments takeplace automatically.
- Advantages
- Reduces overall downtime.
- Spreads data migration across productive operations, minimizing business disruption.
Outcome:
SDMI accelerates go-live by decoupling somedata migrations from downtime, improving system availability during cut over.
Realize Phase – 3. Custom Code Adaptation
After SUM completes, custom code adaptations must be implemented in the converted system to align with the new data model and architecture.
- Adaptation Focus Areas
- Replacing obsolete table references (e.g., BSEG → ACDOCA CDS views).
- Updating SELECTs, joins, and function modules impacted by simplification.
- Switching to S/4HANA frameworks (e.g., BRF+ for output, new credit management, embedded analytics).
- Tools & Process
- Use ATC with S/4HANA checks to highlight remaining issues in the new system.
- Apply transport prepared earlier in the DEV2 sandbox.
- Re-test critical business processes to confirm adaptations work.
Outcome:
Custom code is stabilized and optimized for the S/4HANA environment, ensuring that custom functionality continues to support business operations.
Realize Phase – 4. Cross-Application Follow-On Activities
After technical conversion, several manual, cross-application adjustments are required to fully align the system with S/4HANA.
- Examples
- Database extension adjustments (adapting custom DB structures).
- Migrating legacy output management to the new BRF+ framework.
- Updating authorization concepts (new roles, obsolete objects).
- Enabling and configuring SAP Fiori launchpad and apps.
Outcome:
The system environment is fine-tuned across all applications to align with the S/4HANA platform’s new frameworks and UI.
Realize Phase – 5. Application-Specific Follow-On Activities
Each module may require additional post-conversion manual steps to finalize the setup. These are derived from the Simplification Item Catalog and SI-Check outputs.
- Examples
- Finance: Execute migration programs to complete the transition to Universal Journal.
- Logistics: Adjust Material Ledger settings, update open documents, and reconfigure supply chain processes.
- Industry Solutions: Apply final adjustments or integrate with alternative solutions if some functions are obsolete.
Outcome:
Application-specific follow-ons ensure each business module is functionally ready and consistent after the conversion.
Realize – 6. Data Cleanup (Post-Conversion)
Finally, the system must be cleaned of obsolete data and structures left behind by the conversion.
- Activities
- Run SAP-delivered cleanup reports.
- Remove old tables, indices, or unused configuration elements flagged by SI-Check.
- Decommission legacy data models that are no longer relevant.
Outcome:
The system is leaner, simplified, and free of technical debt — fully aligned with the “run simple” principle of S/4HANA.
SAP Conversion is acomplicated and risky process. It’s always better to do a trial conversion and run through the entire process before enterprises jump into the actual conversion. SAPVISTA offers customized dedicated servers hosted on cloud to facilitate this conversion. SAPVISTA has extensive Conversion experience and has a comprehensive capability to advise the client on a complex conversion.
.webp)
.webp)
