TL;DR

• SAP’s own support strategy page confirms mainstream maintenance for SAP Business Suite 7 core applications, including ECC on Enhancement Packages 6 through 8, ends December 31, 2027. Optional extended maintenance runs through December 31, 2030.
• SAP defines three official migration paths: New Implementation (often called “greenfield”), System Conversion (an in-place technical conversion, often called “brownfield”), and Selective Data Transition (a scoped hybrid, often called “bluefield”). Each changes what you actually need to test.
• We checked seven named competitors. None has published a genuinely complete, structured S/4HANA migration testing checklist. Some lead with case studies and no checklist at all. One page titled “checklist” gives testing two sentences.
• The checklist below is built around SAP’s own tools and its own documented process: the Custom Code Migration app and ABAP Test Cockpit, the Migration Cockpit’s own five-phase workflow, and SAP’s own “Cutover Simulation / Dress Rehearsal” step.
• Sahi Pro fits this specific problem because a migration project often means running old SAP GUI screens and their new Fiori replacements in the same regression suite during the transition, which is exactly the kind of single-flow, cross-interface testing Sahi Pro is built for.

SAP’s own support strategy page states plainly that mainstream maintenance for SAP Business Suite 7 core applications runs “until the end of 2027.” For most ECC customers on Enhancement Packages 6 through 8, that’s the real deadline. Extended maintenance buys three more years, through the end of 2030, at a fee. 

That means any organization that hasn’t started planning a migration is already inside the practical testing window, since testing is usually the single largest time cost in a migration project, and it’s the piece competitor content covers the least well. We checked what seven named test automation and SAP tooling vendors publish on this specific topic. Several lead with case studies and stats. 

One page is titled “S/4HANA Migration Checklist” and gives testing two sentences inside a broader project checklist. None of them has published a genuinely complete, testing-specific checklist. This one is built to actually be that.

Which migration path you’re on changes what you test

SAP’s own documentation defines three approaches. New Implementation (commonly called “greenfield”) rebuilds configuration and master data from scratch, with no historical transactional data carried forward. System Conversion (commonly called “brownfield”) is, in SAP’s own words, “an in-place conversion of the existing ECC system,” where “the full set of data remains in the system.” Selective Data Transition (commonly called “bluefield”) is a scoped hybrid: “a data migration into S/4HANA system with selective scope and individual transformations,” where the original ECC system stays available after the move.

The testing implications follow directly from that. A New Implementation needs full business-process validation, since the configuration is rebuilt rather than inherited. A System Conversion is dominated by regression testing of processes that already exist, plus the custom code and data conversion checks covered below, since business logic mostly carries over unchanged. A Selective Data Transition needs both, scoped specifically to whatever was selectively moved. If your checklist doesn’t start with which of these three you’re actually doing, the rest of it is guesswork.

Custom code testing before you touch production

If your system carries custom ABAP code, and most ECC systems that have run for more than a few years do, SAP’s own tooling for this is specific. The SAP Fiori Custom Code Migration app runs SAP S/4HANA-specific checks on your custom code, executed automatically through the ABAP Test Cockpit (ATC). 

The documented workflow is a five-step process: set up the app in either a cloud-based (SAP BTP ABAP Environment) or on-premise sandbox deployment, collect usage data on your custom code for at least a year using the ABAP Call Monitor or SAP Solution Manager to establish a reliable baseline, let the app calculate a default scope from that usage data with the option to adjust it manually, review the findings organized by complexity and flag high-cost developments for a redesign decision rather than a straight fix, and export the results into SAP Readiness Check 2.0. 

The usage-data step matters most for a checklist: skipping it means testing every line of custom code instead of the code your business actually runs, which is where most of the wasted effort in this phase comes from.

Data migration validation

SAP’s own S/4HANA Migration Cockpit documents its process as five phases: Preparation (setting up the migration project and downloading templates), Data readiness (preparing source data for transfer), Validation (verifying data accuracy and integrity before load), Simulation (testing the migration process before it runs for real), and Execution (the actual data transfer). 

Each phase is a natural checklist gate on its own. Skipping straight from data readiness to execution, without a real validation and simulation pass, is the single most common way migration testing schedules slip, because problems that should have surfaced in simulation instead surface in production.

Business Partner conversion: the master data change most checklists miss

If you’re running a System Conversion, SAP’s own documentation is direct about one requirement: “in preparation of a technical S/4HANA conversion it is mandatory to convert (CVI conversion) Customers and Vendors into Business Partners.” This is a structural master data change, not a cosmetic one, and it’s worth a dedicated line on any checklist rather than folding it into generic “master data testing.” Test the converted Business Partner records against the original customer and vendor data they came from, not just against whether the conversion job completed without errors.

Fiori and GUI testing, side by side

SAP’s own product page states that for private cloud and on-premise deployments, “you can choose when to move to the web-based SAP Fiori user experience, using the SAP Fiori launchpad instead of the SAP GUI for Windows UI,” while Fiori comes as the default, out-of-the-box experience in S/4HANA Cloud. In practice, that choice point means most migrating organizations run SAP GUI and Fiori side by side for some stretch of the project, testing legacy GUI transactions and their new Fiori equivalents in parallel rather than cutting over all at once. A checklist that only accounts for one interface or the other misses exactly the period where testing coverage matters most.

Integration testing for interfaces that change

Migrations frequently change the interface technology underneath a business process even when the process logic itself doesn’t change, moving from IDoc or RFC-based connections toward OData and API-based ones, or changing middleware. Expleo, an SAP testing consultancy, recommends mapping every integration with SAP and non-SAP systems as part of defining test scope, and using service virtualization to simulate external systems or partner integrations that may not be available during your actual test window. That’s Expleo’s stated recommendation, not an SAP requirement, but it’s a practical answer to a real scheduling problem: an interface you can’t test end to end because the other side of it isn’t available yet.

Cutover simulation and dress rehearsal

SAP’s own guidance describes this step directly: “Cutover Simulation / Dress Rehearsal is to test all aspects of the cutover prior to the Production Cutover; emulating the Production Cutover as close as possible including the Cutover Plan, processes, logistics, resources, IT environments etc.” The point isn’t to retest functionality you already tested elsewhere. It’s to prove the team can actually execute the cutover itself, on schedule, in the conditions of the real one, with enough time budgeted to run the simulation again if it fails the first time.

Why 2027 changes the planning math

SAP’s support strategy page states mainstream maintenance for SAP Business Suite 7 core applications runs through the end of 2027, with extended maintenance available for three years after that, through the end of 2030. Testing is typically the longest single phase of a migration project, and it’s the phase every checklist we reviewed from named competitors either skips or treats as an afterthought. An organization planning around the 2027 date needs its testing checklist finalized well before that, not as a late-stage scramble once a go-live date is already fixed.

Where Sahi Pro fits into this

The GUI-and-Fiori overlap described above is the specific problem Sahi Pro’s architecture is built for. Sahi Pro identifies elements by relationship and context rather than fixed DOM position, and runs across SAP GUI, Fiori, the surrounding web layer, desktop applications, mobile, and API calls in a single script, on a proprietary engine rather than a Selenium or Appium wrapper. During a migration, that means the same regression suite can cover a legacy GUI transaction and its Fiori replacement without maintaining two separate automation approaches for the same business process.

Sahi Pro customers report a 90% reduction in regression man-hours and an 80% reduction in test maintenance compared to conventional tools. Those are company-wide figures across Sahi Pro’s 1,000-plus enterprise customers, not a migration-specific case study, and we’re stating them as such rather than implying a migration-specific result we haven’t confirmed.

Ready to see how Sahi Pro handles GUI and Fiori together during your own migration testing? Book a demo and bring the process that’s currently split across two toolsets. We will run it live.

Sources

• SAP Support Strategy: maintenance end dates for SAP ERP 6.0 / Business Suite 7 — mainstream maintenance through end of 2027, extended maintenance through end of 2030, both quoted directly
• SAP blog: Maintenance Timelines for SAP ERP 6.0 (“ECC”) — corroborates the 2027/2030 dates by enhancement package level
• SAP Support: Selective Data Transition Engagement — SAP’s own definitions of System Conversion, Selective Data Transition, and New Implementation, quoted directly
• SAP blog: Custom code analysis for SAP S/4HANA with SAP Fiori App Custom Code Migration — Custom Code Migration app workflow and its use of ABAP Test Cockpit, quoted directly
• SAP blog: SAP S/4HANA Migration Cockpit — the five-phase Migration Cockpit process, quoted directly
• SAP blog: SAP S/4HANA Business Partner Conversion, merge Customer and Vendor into single Business Partner — Business Partner CVI conversion requirement, quoted directly
• SAP product page: SAP Fiori — Fiori as the on-premise/private cloud choice point versus SAP GUI, and default for S/4HANA Cloud, quoted directly
• SAP blog: SAP Project Manager’s Guide to SAP Project Cutover — Cutover Simulation / Dress Rehearsal definition, quoted directly
• Expleo: 5 key considerations for your S/4HANA migration testing strategy — integration mapping and service virtualization recommendation, attributed to Expleo, not stated as SAP guidance
• Tricentis: S/4HANA Migration SAP Test Automation — competitor coverage check, referenced for what Tricentis publishes, not for its specific case-study figures
• Worksoft: 6 Dos and Don’ts to Prepare for Your SAP S/4HANA Migration — competitor coverage check
• Panaya: S/4HANA Migration Checklist for Application Managers — competitor coverage check, confirms testing gets minimal treatment in their “checklist”
• Sahi Pro proof points: internal, per Sahi Pro brand and positioning documentation (90% regression savings, 80% maintenance reduction, company-wide figures)