Planning SAP ECC to S4HANA Conversion

Introduction

Purpose

An SAP ERP 6.0 system (commonly called ECC) holds years of configuration, custom programs and business history. A system conversion lets you carry all of that into SAP S/4HANA in one controlled technical project instead of rebuilding the landscape from scratch. This chapter is the planning foundation for the whole series. It explains what changes between the two products, which route fits which situation, how the project is staged, who owns which task, and how to prepare your data before any technical work starts.

Definition. A system conversion is an in-place transition in which an existing SAP ERP 6.0 system is converted to SAP S/4HANA with the Software Update Manager (SUM). Customizing, custom code and the business data you choose to keep are carried forward. If the source system does not yet run on SAP HANA, SUM can migrate the database during the same procedure by using the database migration option (DMO).

Why it is used. Most organizations that choose a conversion want to keep their existing processes and transaction history while moving to the new data model and the SAP Fiori user experience. A conversion avoids re-implementing every process and re-loading master data, although it does mean you inherit the quality of your current data and custom code.

Who should read this. BASIS administrators, functional leads, ABAP developers and project managers who are planning or supporting an ECC to SAP S/4HANA conversion. You should already be comfortable with a three-system ECC landscape (development, quality, production), the transport system and the basics of SAP HANA.

The table below shows how this tutorial series is organized, so you can see where each part of the conversion project is covered.

Scope and Version Context

This series is written for conversion to SAP S/4HANA 2025. The reference document is the Conversion Guide for SAP S/4HANA 2025; its current edition at the time of writing is document version 2.0 dated 25 February 2026, which covers feature package stack 01 (FPS01). SAP revises these documents regularly, so treat the version on SAP Help Portal as authoritative if it differs from this series. The SAP Notes used in this chapter were checked in the versions available at the time of writing: SAP Note 3549655 (Restriction Note) version 9 of 14 September 2026, SAP Note 3493301 (Release Information Note) version 13 of 29 September 2026, SAP Note 2399707 version 192 and SAP Note 2502552 version 126. SAP updates these notes often, so always open the latest version before you act on a number from this chapter.

The scope is limited to the system conversion path from SAP ERP 6.0. New implementation with the SAP S/4HANA Migration Cockpit, selective data transition and the adoption of SAP S/4HANA Cloud Public Edition are separate projects. They are compared briefly in this chapter only so that you can confirm a conversion is the right route.

Version Note. Some later chapters use screens and lab details from an SAP S/4HANA 1709 conversion. They are always labelled as older-release examples. Tool behaviour, minimum support package levels and SAP Note numbers change between releases, so confirm every note number in this series on the SAP Support Portal before you apply it.

Key Terms for Beginners

If you are new to SAP migrations, a few words appear again and again. Read the table once now and come back to it whenever a term feels unfamiliar. Every term is explained again in the chapter where it matters.

The table below explains the most common terms in simple words.

ECC and S/4HANA Compared

Data Model and Database

The biggest difference between the two products is not the screen. It is what sits underneath. SAP ERP 6.0 runs on several database types. SAP S/4HANA runs only on SAP HANA, an in-memory database. Because of that, SAP removed aggregate and redundant tables that existed only to make reports fast on disk-based databases, and reporting and posting now read the same data.

Example. In SAP ERP 6.0, a goods receipt wrote a header row to table MKPF and an item row to table MSEG, and stock totals were also kept in separate tables. In SAP S/4HANA the same movement is stored as one record in table MATDOC, and totals are calculated from it when needed. For the conversion this means the data is transformed during the SUM run, not just copied.

The table below lists the data-model and functional changes that most often surprise project teams during a conversion. It is not complete; the Simplification Item Catalog is the authoritative list for your exact start release.

Common Error. Treating the conversion as a purely technical upgrade. Because data structures and some functions change, functional teams own a real share of the work, and their effort is often underestimated at the start.

User Interface and Deployment

SAP GUI is still available in SAP S/4HANA, but SAP Fiori is the recommended user experience. Access through the SAP Fiori launchpad is role-based: instead of a long transaction menu, each user sees tiles from catalogs assigned through business roles. If you plan to adopt Fiori, your existing authorization concept needs to be reviewed and the back-end role menus mapped to Fiori catalogs.

SAP Fiori can be deployed in two ways for SAP S/4HANA. The table below compares them so you can choose early, because the choice affects landscape and sizing.

Security Consideration. Plan the authorization work as part of the project, not as an afterthought. Obsolete transactions in existing roles must be reviewed after the technical conversion (Chapter 5 covers this).

Maintenance Timeline

When people say ECC ends in 2027, they mean the end of mainstream maintenance, not that the system stops working. After mainstream maintenance ends, you either buy optional extended maintenance where it is offered, or the software moves to customer-specific maintenance, which has restrictions.

The table below summarizes the published maintenance dates for the products involved. Dates were checked against public SAP announcements and partner summaries; confirm them on the SAP Support Portal before publishing or committing to a project plan.

Version Note. SAP S/4HANA 2025 was released in October 2025 (feature package stack 00) and received feature package stack 01 in February 2026. SAP Note 3493301 states that SAP S/4HANA 2025 is in maintenance until 31 December 2032. Each earlier release, such as 2021 or 2022, has an earlier end date, so confirm the date of the release you run today. The dates for SAP ERP 6.0 enhancement packages 0 to 5 in the table above come from public sources; confirm them in SAP Note 2881788.

Practical point. As of October 2026, roughly fifteen months remain before 31 December 2027. A conversion project that includes analysis, a sandbox, a development conversion, test cycles and a rehearsal rarely fits comfortably into a few months, so teams that have not started are already under time pressure.

Hand-over: the maintenance dates

The project manager takes the dates above to the business owners. They agree the target go-live window and the budget. BASIS and the functional leads start Chapter 2 once the window is agreed, because the schedule of the test cycles depends on it.

Choosing a Conversion Path

Target Deployment Options

Before you plan the technical steps, decide where the converted system will run. The decision affects who operates the infrastructure, how much you can customize, and whether a system conversion is possible at all.

The table below compares the main SAP S/4HANA deployment options from the viewpoint of a conversion project.

Version Note. Older training material mentions SAP HANA Enterprise Cloud (HEC) as a separate hosting model. SAP-managed hosting is now offered under the private edition. Confirm the current commercial packaging with SAP or your account team, as this changes over time.

Useful questions when deciding:

Does your organization have the in-house skills to run SAP HANA and SAP S/4HANA, or do you prefer SAP to operate the infrastructure?

How much custom code and how many modifications do you have? Heavy customization favours on-premise or private edition.

What are your compliance and data-residency requirements?

How much downtime can the business accept for the production cutover?

Do you prefer to buy licences once (on-premise) or to subscribe?

System Conversion Compared with Other Approaches

Short answer. A system conversion keeps your existing system and moves it to SAP S/4HANA. A new implementation builds a fresh SAP S/4HANA system and loads data into it. A selective data transition combines parts of both for special cases.

New implementation and the Migration Cockpit are covered in a separate series. Selective data transition is outside the scope of this tutorial.

Which Source Releases Can Be Converted Directly

Short answer. According to SAP's Getting Started guide for SAP S/4HANA 2025, a one-step conversion starts from SAP ERP 6.0 with enhancement packages 0 to 8, with restrictions for some support package levels that are listed in SAP Note 3549655. This means a system on enhancement package 6 does not have to be upgraded to a higher enhancement package only to be converted. What can force an upgrade first is a different condition: the system is older than SAP ERP 6.0, it is not Unicode, it is a dual-stack system, or its support package level is below the minimum.

Names that confuse beginners. People often say "ECC 7 EHP6" in conversation. There is no separate product called ECC 7. The official name is SAP ERP 6.0, enhancement package 6. SAP Business Suite 7 is the name of the product family that contains SAP ERP 6.0, SAP CRM 7.0 and other applications. When you plan a conversion, always use the official name and read the real release numbers from the system.

You can read the enhancement package from the release of the software component SAP_APPL in System > Status. The table below shows the values that are confirmed in SAP community and partner documentation. Look up the remaining values in SAP's release documentation instead of guessing, because sources differ for some enhancement packages depending on the product variant.

Note. In the Installed Product Versions tab, the product SAP ERP may show the release 2005. This is only the technical name of SAP ERP 6.0, and it does not mean the year 2005 or an old version. Read the enhancement package from the product line "EHP... FOR SAP ERP 6.0" instead.

The table below shows what to do for each type of source system. Use it together with the decision diagram in Figure 1 that follows.

SAP Note 3493301 also defines the minimum support package level of the underlying SAP NetWeaver release for a system conversion to SAP S/4HANA 2025. If your system is on a lower level, you first have to go to one of these levels. The table below lists the values.

SAP Note 3549655 adds one more rule that concerns master data. It applies to systems that contain vendors with assigned contact persons and that are below SAP ERP 6.0 enhancement package 5 (SAP_APPL 605). For these systems you must update to the support package levels in the table below before the conversion, implement corrective SAP Note 2383051 and contact SAP through a customer incident on component AP-MD-BF-SYN for further corrections.

This rule is not relevant if the system has no vendors with assigned contacts. You can check this in table KNVK: if no record has a non-initial value in field LIFNR, the rule does not apply. Use transaction SE16 or SE16N to look at the table with the condition LIFNR not equal to blank.

Figure 1: Decision diagram: can the source system be converted to SAP S/4HANA in one step?

Example. A company runs SAP ERP 6.0 enhancement package 6 on Oracle. The BASIS engineer opens System > Status and confirms the system is Unicode and has no Java stack. She then reads SAP Notes 3549655 and 3493301 and finds that the installed SAP_BASIS support package level meets the minimum. Because the system is on enhancement package 6, the vendor-contact rule for older enhancement packages does not apply. Result: a one-step conversion is possible and no extra enhancement package upgrade is needed. The Oracle database is moved to SAP HANA by DMO in the same run.

Version Note. The minimum support package levels and the list of supported start releases are release-specific. They are defined in the restriction note of each target release, for example SAP Note 3549655 for SAP S/4HANA 2025 and a different note for SAP S/4HANA 2023. Do not copy numbers from an older release into a new project. The numbers in this chapter apply to SAP S/4HANA 2025 only.

Common Error. Concluding "we are on EHP 6, so we must upgrade first" without reading the restriction note. The real question is whether the system meets the requirements for the target release, and the note answers that.

Start Release and System Requirements

Before you open any conversion tool, check that your system meets the entry conditions. A failed requirement found in month one costs little; the same finding during the SUM run can cost a weekend.

The table below lists the entry requirements described in the Conversion Guide for SAP S/4HANA 2025 and where to check each one.

Use the following steps to record your starting point. Each step says where to click and what to write down. The result is the inventory worksheet that follows, and every later chapter relies on it. SAP GUI screens differ a little between versions, so look for the field names and not for the exact position.

1. Log on to the SAP ERP 6.0 system you plan to convert, in the productive client or in a recent copy of production, with a user that may display system information. Do not use an old copy: its software levels may differ from production.
2. In the menu bar choose System > Status. The dialog System: Status opens.
3. In the area SAP System data, read the product version (the field Component version) and the field for Unicode. Write down whether the system is a Unicode system (Yes or No). Field names can differ slightly between SAP GUI versions; verify on your screen.
4. In the area Database data, write down the database system (for example Oracle, DB2, SQL Server, SAP MaxDB or SAP HANA) and its release. In the area with the host and operating system data, write down the operating system and the kernel release if they are shown.

5. Next to the component version, click the magnifying glass icon (component information). The dialog Installed Software opens with two tabs.
6. On the first tab, Installed Software Component Versions, read the columns Component, Release, SP-Level, Support Package and Short Description. Figure 3 shows this tab. Write down the release and the SP-level of SAP_BASIS, SAP_ABA and SAP_APPL.
7. On the same tab, list every component that is not part of the standard SAP core: these are your add-ons. In Figure 3, GRCPINW (SAP GRC NetWeaver Plug-In), MDG_FND, MDG_APPL, MDG_MDC and MDG_UX (Master Data Governance) and ST-PI (Solution Tools Plug-In) are such entries. Use the toolbar button to export the list or copy the lines into a spreadsheet. Chapter 2 checks each add-on in the Maintenance Planner.

8. Click the second tab, Installed Product Versions. Find the product SAP ERP and the line EHP8 FOR SAP ERP 6.0 (or the EHP that your system shows). Figure 4 shows this tab. This is the enhancement package of your system.

Figure 4: Installed product versions of the same system, showing EHP8 FOR SAP ERP 6.0.

9. Compare the SAP_APPL release with the table earlier in this chapter to double-check the enhancement package. In the example, SAP_APPL 618 matches EHP 8.
10. Check whether the system is dual-stack. A dual-stack system has an ABAP and a Java instance with the same SID. Ask the infrastructure team for the instance list, or run the command sapcontrol with the options -nr <instance number> -function GetSystemInstanceList on the server: ABAP instances and J2EE (Java) instances are listed. Verify the command with your infrastructure team. If a Java instance is listed, the system must be split first (SAP Notes 1686144 and 1655335). See Figure 5.
11. Open transaction SFW5 and write down the active business functions. Chapter 2 explains why a business function that is switched on in ECC and always off in SAP S/4HANA blocks the conversion. See Figure 6.
12. Open transaction SPAM and read the version in the title bar. Write it down. It must be patch 71 or higher before the preparation in Chapter 3. See Figure 7.
13. Select the scope. Under Check for Productive Client(s), tick the analyses you need. The table after this step explains each option. Under Check for Client 000, tick Simplification Item Consistency only when you run the report in client 000.
14. The table below explains the options of the report. They match the areas of the Readiness Check dashboard. Check the SAP Readiness Check documentation for the current wording of each option.

Read SAP Notes 3549655 and 3493301 and compare the SAP_BASIS support package level, the vendor-contact rule and the add-on restrictions with your worksheet.

Open the PAM and check that your planned operating system and SAP HANA version are supported for SAP S/4HANA 2025.

Record every gap in the worksheet with an owner and a date.

The table below is a worksheet that you can copy. Fill the last column with the values you found in the steps above. The third column shows what SAP S/4HANA 2025 expects, as described earlier in this chapter.

Hand-over: the worksheet and its gaps

BASIS shares the filled worksheet with the project manager, the functional leads, the ABAP lead and the infrastructure team. Every gap goes to an owner: a system that is not Unicode goes to the Unicode conversion project, a low support package level goes back to BASIS for a support package update, a dual-stack system or an unsupported platform goes to the infrastructure team.

When an owner has closed a gap, BASIS repeats the check on this page and updates the worksheet. Chapter 2 starts when no blocking gap is open.

Project Lifecycle

SAP Activate Phases

SAP Activate describes a project in six phases: Discover, Prepare, Explore, Realize, Deploy and Run. A conversion follows the same phases but the content is different from a new implementation. In a conversion, the Explore phase is mostly analysis, because tools tell you what must change, whereas in a new implementation it is dominated by process workshops.

Figure 8: SAP Activate phases and the conversion-specific work done in each phase.

Figure 8 shows the phases from left to right. The table below explains what each phase achieves in a conversion and what you should have in hand when it ends.

The table below links each phase to its typical outputs.

Landscape and Test Cycles

Short answer. SAP recommends converting a copy of your development system first, collecting every required change in transport requests, and then replaying those changes during the real conversion of production. This is called a distributed system landscape approach.

Figure 9: Test conversion on a second development system, with collected transports used for the production conversion.

In Figure 9, DEV keeps serving normal support work while DEV 2 is used for as many test conversions as needed. Changes that can only be made after the conversion, such as the finance customizing, are recorded in transport requests. SUM later accepts those transport requests as input during the real production conversion, so the production downtime is not spent discovering changes.

The following steps describe how to use the second development system. Your team may add or reorder steps to fit its landscape.

1. Create DEV 2 as a system copy of DEV, while DEV continues to receive normal fixes.
2. Run the Prepare-phase checks on DEV 2: Maintenance Planner, SI-Check and custom code analysis.
3. Convert DEV 2 to SAP S/4HANA with SUM and note the runtime of each phase.
4. Collect all required changes in transport requests, including customizing that can only be done after the conversion.
5. Provide those transport requests to SUM when you convert the next system in the landscape.
6. Repeat the conversion on a fresh copy if the result is not yet stable, rather than patching a half-converted system.

After DEV 2 is created as a system copy, it still holds the settings of the original system. Do the tasks in the table below before the first conversion test. They are general BASIS practice for any system copy and are not specific to SAP S/4HANA. Adapt them to your company standards.

Hand-over: DEV 2 is ready

BASIS signs off the post-copy checklist and tells the project manager that DEV 2 is available. The functional and ABAP teams receive the client and the test logins for Chapter 2. Nobody changes DEV 2 outside the project plan, because later cycles are compared with it.

Many projects run several conversions with different goals. The table below shows a common pattern. It is project practice, not an SAP requirement, so adapt it to your landscape.

Prepare and Realize Sequence

The Conversion Guide describes a recommended order of work, shown in Figure 10. Steps 2 to 4 are recommended in that order, but SAP states that they can technically be done independently or in parallel.

Figure 10: Recommended order of work in the Prepare and Realize phases of the conversion.

The table below states which steps are mandatory and what each one delivers.

Two tools are easy to confuse. The table below compares them.

The table below compares SAP Readiness Check and the Simplification Item-Check (SI-Check), based on the Conversion Guide.

Expected Result. SUM runs the SI-Check at the start of its procedure and again just before the downtime. At the start it stops on a message with return code 12; before downtime it stops on return code 8 or higher. Fixing all inconsistencies early therefore protects your downtime window.

Run, share, fix, run again. Almost every check in the next chapters follows the same loop. The BASIS team runs the tool, but BASIS does not own most of the findings. The report is shared with the team that owns each finding, that team fixes its items in the SAP ERP 6.0 system, and BASIS then runs the check again to confirm. The loop repeats until no blocking item is left. Plan time for this: each loop can take days, because the owners need time to fix their items. This is one more reason to start the checks early.

Use the following steps for every check. They apply to the SAP Readiness Check, the Simplification Item-Check, the custom code analysis and the finance checks alike.

1. BASIS runs the check and saves the result with the date, the target release and the versions of the SAP Notes that were used (export the list or save a screenshot). A result without a date cannot be compared with the next run.
2. BASIS splits the result by owner and sends each team only its own items, with the SAP Note number of every item. Do not send the whole report to everybody: nobody will read it.
3. Each owner team fixes its items in the SAP ERP 6.0 system, not in SUM, and writes down what was done and who confirmed it.
4. BASIS runs the check again. For the Simplification Item-Check you can run only the single items that were fixed. Update the status of every item: open, fixed or exempted with a reason.
5. Repeat until no blocking item is left, then keep the final result as evidence for the project.

The table below shows who normally owns which kind of finding and who runs the check again.

Team Responsibilities

Roles and Hand-offs

A conversion is a team project. The technical conversion is run by the Technology (BASIS) team, but the checks, the code, the roles and the business validation belong to others. Naming owners early prevents the common situation where everybody assumes a task belongs to somebody else.

The table below lists typical responsibilities. Adapt it to your organization.

Figure 11: Main hand-offs between the conversion teams.

Example. Imagine the BASIS team finishes the SUM run on DEV 2. The system goes to the ABAP team, who work through the modification and enhancement adjustments and fix findings from the ABAP Test Cockpit. When the code compiles and activates, the functional team starts the post-conversion finance steps and testing, while the security team reviews role menus in parallel.

Version Note. A SUM dialog seen in an SAP S/4HANA 1709 lab states that SPAU adjustments can be made without an object registration key for 14 days after the phase is first entered. This is an older-release observation; check the current SUM guide before you rely on it.

Data Strategy

Data Volume Reduction

Short answer. You do not have to carry every historical record into SAP S/4HANA. A smaller database converts faster, because the load size is smaller, and it is cheaper to run on SAP HANA memory.

SAP Data Volume Management (DVM) supports this work. Typical aids include the DVM Work Center in SAP Solution Manager, the Guided Self Service that produces a best-practice document showing where data can be reduced most efficiently, and the reorganization and compression tools that simulate the savings. You can also simulate the future size of your system to forecast the effect of planned measures. Archiving itself is performed with the archive administration transaction SARA.

A simple way to start is to sort data by how much the business still needs it. The groups below are a planning aid created for this tutorial, not SAP product terms.

Common Error. Archiving data that finance still needs for migration, such as open items and balances, or data that an open business process still uses. Agree the scope with finance and auditors, and test the archiving run on a sandbox copy first.

Hand-over: data volume and retention

The finance team and the auditors decide which data may be archived and for how long. BASIS runs the archiving on a test copy and reports the new database size. The data owners check that old documents can still be read. Only then the same steps are planned for production, and the size is measured again in the next cycle.

Common Mistakes and Troubleshooting

Planning Mistakes and Prevention

What can go wrong? Most conversion problems that appear late were visible early. The table below lists frequent planning mistakes, their effect and a way to prevent them.

The table below connects each mistake to its consequence and prevention.

Troubleshooting. If the plan slips, first check three things in order: whether the Maintenance Planner result changed, whether new red messages appeared in the latest SI-Check run, and whether the latest conversion test ran on a copy that is still close to production size.

Summary

Key Takeaways

A system conversion moves an existing SAP ERP 6.0 system to SAP S/4HANA with SUM, with optional database migration in the same run.

The ECC date that matters is the end of mainstream maintenance: 31 December 2027 for enhancement packages 6 to 8, with optional extended maintenance until 2030.

System conversion is supported for on-premise and private cloud edition; the public edition is a new implementation.

Entry requirements: Unicode, AS ABAP only, SAP ERP 6.0 enhancement package 0 to 8 at the required support package level, and supported add-ons and business functions. Enhancement package 6 does not need an extra upgrade.

SAP S/4HANA 2025 is in maintenance until 31 December 2032 according to SAP Note 3493301.

Use a second development system for test conversions and collect required changes in transport requests.

Maintenance Planner and the SI-Check are mandatory; SAP Readiness Check is a highly recommended planning tool.

Name owners for BASIS, functional, ABAP, security, Fiori and business testing from the start.

Reduce data volume before converting.