SAP Testing Services for S/4HANA Conversions and Support-Pack Cycles
Contract SAP test leads, Tosca automation engineers and functional testers, booked per conversion cycle.
Who runs the tests on mock conversion two? If it’s your controller, keep reading.
SAP testing services put a contract test lead, Tricentis Tosca automation engineers and functional testers on an S/4HANA conversion’s mock runs, dress rehearsal and support-pack regression. KORE1 staffs them per cycle, so SI consultants and key users keep building.
Last updated: October 18, 2026
Most conversion plans name a test lead and quietly assume the rest. The SI’s functional consultants will execute scripts between configuration tasks, and the finance and supply chain users who know the processes will pick up whatever is left after hours. Neither holds for long. Ask anyone who’s tried.
Both break the same week. Usually it’s the second mock, when the build is still moving and the script count jumps from about a hundred to several hundred. Something gives. Usually the dates.
We fill that gap with people whose only job is the test cycle. They arrive before the first mock, stay through the dress rehearsal, and leave a regression suite behind for the support packs that follow. Then they go.
- This page
- The SAP test cycles of a conversion and after it. What each run tests, who executes it, and the contract test team we put on it.
- Routed elsewhere
- Testers for web, mobile and product releases sit with QA staff augmentation. Covering the day job of process owners who sign UAT is ERP program team staffing. Load rehearsal and reconciling balances after a load belong to ERP data migration specialists.
The test team comes from KORE1’s SAP consultant staffing desk, which has been filling SAP seats since 2005, and it works next to the functional and technical consultants on our S/4HANA consultant staffing bench. Every seat runs on contract staffing terms, booked to a run rather than a calendar quarter. Programs on Oracle, Dynamics or another ERP run through our ERP consultant staffing desk the same way.
Five SAP Test Runs Before Production Sees One
A conversion is a crash test you get to repeat. Each run converts a copy of production, so the program finds out what breaks before production does. Five runs, below. Test hours for each, and who executes them, on a typical ECC brownfield conversion.
Run 01
Mock conversion 1
The technical run. SUM converts a copy of production and everyone learns how long it takes and what stops it. Testing here is smoke checks and log review, mostly ours.
Test team 90 hKey users 10 h
Run 02
Mock conversion 2
First full functional pass on converted data. End-to-end integration tests for order to cash, procure to pay and record to report, plus every interface that feeds them.
Test team 400 hKey users 80 h
Run 03
Mock conversion 3
Full regression and user acceptance. The business signs off here, so key-user hours peak. Testers stage the data and file the evidence. Users accept.
Test team 480 hKey users 240 h
Run 04
Dress rehearsal
The cutover run, timed against the real downtime window on production-sized data. Smoke tests and the reconciliation sign-off happen on the clock.
Test team 110 hKey users 30 h
Run 05
Go-live weekend
The same smoke set on production itself, split between testers and the people who will use the system on Monday morning.
Test team 24 hKey users 24 h
Executed by the contract test team.
Stays with your key users, mostly acceptance and sign-off.
Across five runs, 1,488 test hours. The test team carries 1,104 of them, and your key users keep 384, about a quarter.
Look at run three. It’s the one that eats programs. User acceptance and full regression land in the same window. The build is supposed to be frozen and usually isn’t, and someone still has to stage test data, execute 960 scripts and log every defect with evidence a steering committee will accept.
Without a test team, those 480 hours go back to people already carrying the program. SI consultants stop configuring to execute scripts. The fixes stall. Key users test at night.
That’s how a three-mock plan becomes four, and a big part of why ERP implementations run longer than planned. Nobody budgets the fourth.
Why ECC’s End Date Turns Into Three Mock Conversions
SAP’s maintenance strategy for Business Suite 7 ends mainstream maintenance for ECC 6.0, on the three most recent enhancement packages, at the end of 2027. You can buy extended maintenance to the end of 2030, and it costs an extra two percentage points on your maintenance basis.
After that comes the transition option, a subscription that keeps ECC running inside SAP ERP, private edition. It was announced for 2031 to 2033, and in October 2026 SAP said subscriptions may run until the end of 2035, with further prerequisites, for systems moved onto private edition on HANA before 2031. Later, yes. Not free, and not without a move.
Every one of those paths ends in a conversion. Nobody converts production on the first try. SAP’s own conversion guide recommends a test conversion in a dedicated system early in the project, and programs keep repeating it until the run gets boring.
Two mocks at minimum. Three, plus a dress rehearsal, is a common plan. Each one is a full test cycle with a different job.
Mock 1 finds the technical stoppers
Simplification items nobody cleared, custom code still selecting from tables S/4HANA replaced, a batch job that worked on ECC and quietly fails on the new data model, or a conversion run that blows through its downtime window. Test scripts are light. The logs talk.
Mock 2 proves the processes
End-to-end scenarios on converted data, every interface live. The hard one. A test lead who has run SAP integration testing earns the rate here.
Mock 3 is the one you sign
Regression, acceptance and the defect burn-down the steering committee reads before it agrees to a cutover date. Then it signs.
The conversion itself belongs to your SI and the SAP Basis administrators who run it. The testers make sure each run tells you something true. That’s the job. The precheck items those consultants clear are walked through in our S/4HANA consultant interview questions.
SAP Regression Testing Doesn’t Stop at Go-Live
From the 2023 release on, SAP ships a new S/4HANA release every two years, with feature packs every six months for the first two years and support packages for corrections after that. Its release and maintenance strategy strongly recommends applying support package stacks at least once a year. Public Edition customers get no say. Upgrades arrive every February and August.
Each of those is a support-pack cycle. Each one needs the same regression set run again. By hand, on a mid-market system, that’s a few hundred scripts and a couple of hundred hours per cycle, landing on the same key users who signed off the conversion. Every time.
Tricentis sells its SAP testing through SAP as solution extensions that plug into SAP Cloud ALM. Two matter here. SAP Enterprise Continuous Testing by Tricentis is model-based automation, built so one test module runs across releases. SAP Change Impact Analysis by Tricentis, which now includes LiveCompare, maps what a released transport or a newly landed support pack touches before anyone runs a test, so the regression run can shrink to the processes that changed.
So the cheapest moment to build automation is during the conversion. The regression scripts are being written anyway. A Tosca engineer who automates mock 3’s regression set hands you a suite that runs again on the next support pack, and the one after. Manual testers still cover what changed.
The suite covers what shouldn’t have. Big difference.
Programs that also need someone to own the system after cutover can pair this with SAP application management staffing, which keeps a named pod on your ECC or S/4HANA system between releases. The first weeks after cutover usually sit with a go-live hypercare team.
End of 2027
when SAP Business Suite 7 mainstream maintenance runs out
+2 points
on your maintenance basis to extend ECC support to 2030
17 days
average days to fill a KORE1 IT search
92%
of our placements that last past their first year
Maintenance dates and premium from SAP’s Business Suite 7 maintenance strategy. KORE1 placement data, 2026.
How Our SAP Testing Services Staff a Program
Five steps, in order. Easy start. The first one needs nothing from you but a plan.
Send the mock schedule
Dates for each mock and the dress rehearsal, the modules in scope, and whether the SI has already named its own test lead or expects you to supply one.
Size each run
We count scripts and hours per run and mark which hours have to stay with your key users. That split sets the team.
Meet a shortlist
Testers screened on your modules and your tooling, Tosca or manual, usually inside a week of the call.
Run the cycles
The team joins a few weeks before mock 1, works to the SI’s plan, and files evidence in your test management tool.
Taper to a regression pod
After hypercare most of the team rolls off. One automation engineer can stay for the support-pack cycles, or convert.
Who owns the test plan when an SI runs the program? Usually the SI. That’s fine. Our testers work to its plan, in its defect workflow, and the evidence they write lands in your project documentation instead of a partner workspace.
Independent execution still matters. A consultant who configured a process isn’t the best person to prove it works, for the same reason nobody lets a developer approve their own code, and the auditors who read your test evidence later know the difference.
Seat lengths are booked to a run, the same logic as our SAP staff augmentation contracts and the wider staff augmentation services practice, so a tester who joins for mock 2 isn’t billing through a quiet month in between.
Four Seats on an SAP Test Team
Most conversions need all four for at least one run. Each card says what the seat hands back.
Lead · Contract
SAP test lead
Owns the test plan per run, the defect triage call, and the exit report the steering committee signs.
Automation · Contract
Tosca automation engineer
Turns the regression set into automated cases that rerun on every mock and every support pack.
Execution · Contract
Functional SAP testers
Execute FI, CO, SD, MM and PP scripts on converted data and write defects a consultant can act on.
After go-live · Contract-to-hire
Regression owner
Keeps the automated suite green between support packs, and often converts into a permanent role.
Functional testers come off the same bench as our SAP FICO consultants. They read a posting log without asking for help. Automation engineers come through our test automation engineer staffing desk, screened for SAP GUI and Fiori work specifically, because a framework engineer from web testing will need months to learn what an SAP transaction does under the hood.
Different animal. Permanent QA hires outside SAP go through QA engineer staffing.
The regression owner is the seat worth converting. We set it up as contract to hire from the start. 92% of our placements make it past the one-year mark. Current contract rates for SAP functional seats are in our ERP consultant hourly rate guide, and we quote each test seat before the first interview.
Converting? The permanent band is in our S/4HANA consultant salary guide.
Common Questions
What do SAP testing services cover on an S/4HANA conversion?
A contract test team for every run on a copy of production. That means test planning, script execution, defect logging and sign-off evidence for each mock conversion and the dress rehearsal, then a regression suite you keep for the support packs that follow go-live. Configuration and the conversion itself stay with your SI.
How many mock conversions should we plan for?
Two at minimum, and three plus a dress rehearsal if the system carries much custom code or a long list of interfaces. SAP’s conversion guide recommends a test conversion in a dedicated system early on. Every extra run costs less than finding the same fault on go-live weekend.
Do we need Tricentis Tosca, or can we test by hand?
Fair question, and for the conversion alone manual execution can work. Automation pays back afterward, because the same regression set runs again on every support package stack, and SAP recommends applying those at least once a year. Customers on SAP Enterprise Support can also use Tricentis Test Automation for SAP with Cloud ALM as a term license, which changes the math.
Why not let the SI’s consultants run the tests?
Because every hour they spend executing scripts is an hour they aren’t fixing what the scripts found. On mock 3 in our example that’s 480 hours. Most integrators are happy to keep test design and triage. Execution moves to us.
What does a contract SAP tester cost?
$130 to $220 an hour is our 2026 rate-guide band for SAP contractors placed through a staffing firm, and general QA testers run $65 to $100. Where a test seat lands depends on how much module depth it needs. We quote every seat before the first interview.
Does S/4HANA Cloud Public Edition change the testing?
Yes. Upgrades come to you every February and August, so regression testing becomes a calendar event instead of a project, and an SAP blog on the process puts the regression window at two to four weeks. SAP’s Test Automation Tool ships preconfigured automates for its standard scripts. Your own extensions and integrations still need people.
How early should the test team start?
Start a few weeks before mock 1. Not the week of mock 2. Our average fill time on IT searches is 17 days, and the seats on a test team are searched together. The test lead goes first so the scripts exist before the testers arrive.
Send the Mock Schedule. We’ll Size Every Run.
Send the dates for each mock and the dress rehearsal, plus the modules in scope. We’ll come back with the test hours per run, the share that has to stay with your key users, and the team that covers the rest.
Plan Your Test Cycles →Hiring conversion consultants too? Start with how to hire an S/4HANA consultant.
