The deadline is real: SAP will end mainstream maintenance for ECC by December 31, 2027. But what most organisations miss is that preparation for S/4HANA is not just a technical prerequisite; it’s a business simplification opportunity. Done right, the preparation phase identifies where your landscape can be streamlined, what can be archived or retired, and where years of accumulated complexity can finally be unwound. The result is a leaner runtime, a smaller data footprint, and a system primed for conversion.
SUMMARY: This blog outlines why preparation for S/4HANA is a business simplification opportunity. It covers readiness checks, Simplification Item check, custom code analysis, data cleansing and archiving, CVI, Unicode conversion, Maintenance planner, Cloud-ALM and system sunsetting; compares Greenfield, Brownfield and Selective Data Transition; and reviews technical prerequisites, HANA options, pre-checks and Basis work to reduce migration time, avoid costly surprises and manage technical debt, data quality, resource capacity and change management risks.
The deadline is real: SAP will end mainstream maintenance for ECC by December 31, 2027. But what most organisations miss is that preparation for S/4HANA is not just a technical prerequisite; it’s a business simplification opportunity. Done right, the preparation phase identifies where your landscape can be streamlined, what can be archived or retired, and where years of accumulated complexity can finally be unwound. The result is a leaner runtime, a smaller data footprint, and a system primed for conversion.
This blog, the second in our blog series, breaks down the critical preparation steps – from readiness checks and custom code analysis, to data cleansing and Customer/Vendor Integration – so you can enter your migration project with clarity.
Why is preparing for an S/4HANA project critical?
Preparation is where the real value of an S/4HANA project begins. By systematically analysing your existing ECC system, cleansing data, and aligning your technical foundation, you avoid the costly surprises that derail migrations mid-flight. The work of preparing to migrate pays dividends in your existing landscape long before any cutover takes place.
The key preparation steps include:
- SAP Readiness check and Simplification Item check: These tools analyse your existing ECC system to identify compatibility issues, required functional changes, and necessary add-ons for S/4HANA.
- Customer/Vendor Integration (CVI): A mandatory pre-step for brownfield conversions. Customers and vendors must be converted into the SAP Business Partner (BP) model before the system can move forward.
- Custom code analysis: Use the ABAP Test Cockpit (ATC) to scan custom code (Z-code) for S/4HANA compatibility. Identify obsolete code that can be retired, reducing the scope of remediation.
- Data cleansing and archiving: Analyse and reduce data volume by archiving obsolete records. This significantly lowers migration time, improves system performance, and reduces expensive in-memory storage requirements on HANA.
- Unicode conversion: Your source system must be running on Unicode: this is a strict requirement for S/4HANA, with no exceptions.
- Maintenance planner: Run this tool to verify add-on compatibility, browser support, and to generate the stack XML file required for the upgrade.
- Cloud-ALM: Existing Enterprise Customers of SAP can also utilise CALM and benefit from using the free services of Cloud-ALM to assist with preparation work for their eventual migration to S/4HANA.
- System sunsetting: A full evaluation of the existing landscape will be conducted, and any systems that are identified as unnecessary or replaceable will be removed (such as removing Solution Manager and implementing CALM, or using an embedded Gateway).
Choosing your migration strategy
Before diving into technical work, you need a clear strategic direction. Our first blog introduced the three primary migration paths; this is how they shape your preparation:
- Greenfield (New Implementation): A blank-slate rebuild. This approach allows you to completely redesign business processes and adopt standard SAP best practices. It offers the highest transformation value but demands the most rigorous change management.
- Brownfield (System Conversion): Convert your existing ECC system directly to S/4HANA, fully retaining historical data, configurations, and past customisations. Often faster, but it carries the risk of bringing legacy technical debt into the new environment.
- Selective Data Transition: Create a new S/4HANA system and selectively migrate only the specific historical data, company codes, or entities that are strictly necessary—leaving behind unnecessary legacy data.
Your choice of path directly determines which preparation steps are mandatory and which are optional. Brownfield conversions, for example, require CVI completion and extensive custom code remediation. Greenfield deployments shift the burden toward process redesign and data migration planning.
| Be SMART: At EPI-USE Labs we have created and perfected our own SMART methodology – where we integrate best use cases with our IP-leveraged Services and Products. We use components from our Data Sync Manager Suite called System Builder, Shell Sync, Client Sync and Data Secure to create new consistent environments from your Production systems with a fraction of the overhead costs, with the added benefit of having fresh and anonymised test data for your development and testing teams. |
Before preparation for the actual S/4HANA conversion begins, your system must meet several baseline requirements. If any of these are unresolved, they become your first order of business.
Split Dual-Stack Systems (ABAP + Java)
If your existing ECC 6.0 system runs on a dual ABAP and Java stack, you must split it into two separate stacks. Only the resulting ABAP-only stack can be converted to S/4HANA. If your landscape contains no dual-stack systems, skip this step entirely.
Unicode Conversion
S/4HANA is shipped exclusively with Unicode, and the SUM process does not include a non-Unicode-to-Unicode conversion for a 7.5x target. If you also need to upgrade your source environment to ECC 6.0, you can combine both steps using the Combined Upgrade & Unicode Conversion (CU&UC). Converting to Unicode is a mostly technical exercise with minimal functional impact beyond regression testing of interfaces, self-services, and custom ABAP code.
Upgrade to ERP ECC 6.0
Your source system must be at minimum on ECC 6.0, since older SAP R/3 4.7 and SAP ECC 5.0 releases do not include the Customer/Vendor Integration (CVI) required for S/4HANA. The specific Enhancement Package version does not matter. If your system is also not yet on Unicode, you may be able to combine the upgrade with the Unicode conversion.
Once these baseline requirements are met, you can proceed to the core preparation phase.
Core preparation activities
Remove or archive old data
Before moving to SAP HANA or S/4HANA, understand the business case for minimising excess data. HANA's in-memory architecture uses significantly more expensive hardware to store data compared to traditional databases – carrying unnecessary historical records inflates both migration time and ongoing infrastructure costs.
Use this as an opportunity to clean up your entire system landscape. Embrace that Production archiving project you have been deferring. Reduce compliance risks associated with data privacy regulations. And remember: non-production systems often store more configurational and development data than Production. Further reduction is achievable through right-sizing non-production environments and removing unneeded data from Production.
Categories to think about when considering your data footprint:
Data ownership
Master data / transactional data
(Hint: you can archive the latter)
Legal compliance data
(What do you need to keep around and for how long?)
Privacy / GDPR
(Related to above, but think about non-production systems)
Hot/warm/cold storage
(S/4HANA requires hot storage)
Temporary data
(Do you have any old staging data you can drop?)
Housekeeping / technical data
(See SAP note 2388483)
| We offer a Pre-S/4HANA System Landscape Optimisation (SLO) engagement to reduce your data footprint before conversion, streamlining the entire project. You can also create lean, secure non-production systems with Data Sync Manager at any time, leveraging our Data Privacy Suite as part of your data privacy toolkit. |
Clean up custom code
If you have been running SAP ECC for years, you almost certainly have a significant inventory of custom ABAP code. The pathway to S/4HANA requires that all custom code be updated to replace deprecated statements with new equivalents. The best place to start? Eliminate custom code that is no longer used – why waste remediation effort on dead code?
The key tools for this work are as follows:
- SAP Code Inspector (SCI): Your first-line analysis tool for identifying code quality issues.
- ABAP Test Cockpit (ATC): A more advanced tool that can perform S/4HANA semantic checks on your custom ABAP code. ATC has specific NetWeaver stack requirements; one proven approach is to stand up a separate ABAP instance at the required software level and use it to perform remote code analysis of your ECC environment without loading anything on your production system.
- Custom Code Analyzer: Part of the formal S/4HANA conversion toolset. It evaluates your code against the Simplification Lists. See SAP Note 2185390 for details.
If you also need to perform a Unicode migration or an upgrade, both processes will involve additional custom ABAP code remediation. For HANA database compatibility specifically, ABAP code generally runs on HANA without changes – with the exception of any database-specific code. Details can be found in SAP Note 1912445.
Migrate your database to HANA (optional)
You have a strategic choice here: migrate to HANA before converting to S/4HANA, or combine both into a single step.
- HANA First (Business Suite on HANA / BSOH): Migrate your non-HANA database to HANA while staying on ECC 6.0. This has far less business process impact than a full S/4HANA conversion and gives your Basis teams the opportunity to become familiar with administering HANA, its architecture, and its hardware requirements.
- All-In-One (DMO with SUM): Your database migration to HANA happens as part of the Software Update Manager (SUM) process when converting to S/4HANA. This approach consolidates testing but increases the scope of a single cutover event.
The right choice depends on your risk appetite and timeline. Some organisations prefer the incremental approach for stability; others want to test once and go all-in. While the HANA-first approach may not be common, it might suit certain scenarios better than a big bang approach.
Note: The move to NetWeaver Stack 7.5 has specific database source version requirements. Your pre-existing database must be upgraded to a minimum level before you proceed – for the HANA database, this minimum is SPS09, revision 97. Consult SAP Note 2158828 for details.
Run pre-checks
The formal pre-check phase uses SAP tools – primarily the S/4HANA Readiness Check – to analyse your existing ECC system and identify impacted business processes (via the Simplification List) and affected custom ABAP code (via the Custom Code Migration Worklist).
| We also offer a complimentary Transformation Assessment report. The process is straightforward: import a small transport into your ECC system, run a report that produces a metadata extract in clear text, and return it to us via a secure portal. No actual client data is included – only version tables, row counts, and specific configuration values that provide a quantitative view of your system's readiness. |
Customer/Vendor Integration (CVI)
CVI is a mandatory pre-step for brownfield conversions. It converts your existing customer and vendor master records into the SAP Business Partner (BP) model – the only master data model supported in S/4HANA. Key activities include:
- Activate PPO (Post Processing Office): Enable this to manage the automatic creation of Business Partners during the CVI process.
- Define BP Roles and Number Ranges: Map existing customer and vendor account groups to new BP roles and groups to ensure consistency.
- Validate Data Integrity: Run reports to verify the consistency of customer and vendor data in your source system (KNA1/LFA1 tables) before migration.
Technical preparations (Basis)
Your Basis team plays a critical role in the preparation phase, apart from the other activities required to prepare your landscape on a technical level. These include:
- SAP Note Application: Basis consultants must apply the necessary SAP notes to the ECC server to prepare the system for migration.
- Backup Production: Perform a full backup of the production system to the development environment to ensure a secure fallback point.
- Finalise Transport Requests (TRs): Close and move all near-completed transport requests to reduce technical conflicts during the conversion phase.
Frequently Asked Questions (FAQs)
Q: Why is migrating to SAP S/4HANA a critical priority right now?
A: Following the 2027 end of mainstream maintenance for SAP ECC (Business Suite 7), SAP offers an optional Extended Maintenance phase from 2028 to 2030. After 2030, all systems automatically transition to Customer-Specific Maintenance, where fees remain but standard support, Service Level Agreements (SLAs), and new legal updates are discontinued. Running unsupported enterprise software introduces escalating risks across cybersecurity, financial reporting, and regulatory compliance. Furthermore, as the deadline approaches, organisations will face a shortage of experienced implementation partners – compressing timelines and increasing execution risks.
Q: What is the true ROI and business value of the migration for S/4HANA?
A: S/4HANA is not just an IT upgrade – it is a catalyst for business simplification and operating model modernisation. The platform provides real-time analytics, enables faster period-end financial closings, and paves the way for advanced automation and AI capabilities. From a quantifiable standpoint, SAP reports that S/4HANA can drive a 10-15% increase in productivity, a 10–15% reduction in logistics costs, and 25-30% shorter production cycles. IT operating costs can also drop significantly, as the architecture requires up to 10x less data storage and allows for 10x faster backups.
Q: What steps minimise migration time to S/4HANA and ensure the new system performs optimally?
A: Data cleansing and archiving is the critical lever. By analysing your data volume and archiving obsolete records before the move, you significantly lower overall migration time and improve the target system's performance. A lean environment is also less prone to data errors during the conversion process itself.
Q: What are the greatest execution risks associated with the migration to S/4HANA?
A: The most significant risk is treating the migration strictly as a technical IT event rather than a business-led transformation. If the transition does not prioritise organisational change management – if the workforce does not buy into newly standardised processes – the project will face defects and quality problems at cutover. Other major failure points include poor legacy data quality, insufficient resource capacity, and a failure to address accumulated technical debt and custom code.
This is the second episode in a multi-part series on navigating the path to S/4HANA. Stay tuned for upcoming episodes covering cloud endpoints, on-premises deployment, AI integration, and project support.