Mainstream maintenance ends, but your factories, payroll and month-end don't. That's the central constraint behind SAP implementation services in 2026. Most bids will sell you a migration route and a toolset. What decides whether you go live safely is different. It's whether you've protected daily operations through cutover and whether you've made honest decisions about the custom code and processes you've carried for years.
Table of Contents
- Pick the Migration Path Before You Talk to Vendors
- Choose a Delivery Model and Partner Mix
- How to Run Discovery, Design and Governance
- Decide What to Keep, Fix or Retire in Custom Code
- How to Migrate Data With Reconciliation Controls
- Protect Daily Operations Through Testing and Cutover
- Confirm Readiness Before You Sign
Pick the Migration Path Before You Talk to Vendors
SAP has stated that mainstream maintenance for Business Suite 7, including ECC 6.0 enhancement packages 6 through 8, ends on 31 December 2027, as reported in coverage of SAP S/4HANA migration in Germany. That date sets a constraint, not a project schedule. Choose the migration path before inviting vendors to price the work. Otherwise, you risk comparing bids built around different assumptions about scope, staffing and operational disruption.
Market figures can help assess demand for specialist skills, but they cannot set your go-live date. The reporting puts the worldwide ECC customer base at approximately 35,000, and estimates that about 39%, roughly 14,000 organizations, had started or completed the move by the end of 2024. Treat these as reported estimates, not a forecast for your programme.
Migration paths compared
| Path | What changes | Planning assumption to validate with bidders | Best fit |
|---|---|---|---|
| Greenfield new implementation | Processes and data are redesigned from scratch | Ask bidders to build a timeline from scope and dependencies | Many legacy systems, post-merger environments, or substantial process change |
| Brownfield system conversion | Existing configuration, data and custom code are converted in place | Ask bidders to identify what could extend the schedule | Stable ECC with limited customisation to retire |
| Selective data transition | Selected company codes or processes move, while some history stays behind | Ask bidders to specify selection and reconciliation work | Multi-entity groups seeking a clean start for some units |
| Cloud-hosted new build | A new system is built on a managed cloud platform using standard processes | Ask bidders to state what standardisation the schedule assumes | Organizations ready to standardise with limited in-house SAP skills |
Do not treat these as typical durations. They are planning assumptions to test with bidders, based on your system count, integrations, regulatory requirements and custom processes. Any schedule that omits those dependencies is optimistic. Ask each bidder to show which decisions, resources and operational constraints support its estimate, and what would change it.
Three questions to answer first
- How many systems feed the ERP? Count legacy systems and company codes, not just the ECC system in scope.
- How much history must stay live? Ask audit and tax teams what belongs in the new system and what can remain in an archive.
- Which custom code is in use? Export usage for the last twelve months before asking vendors to estimate remediation.
If you cannot answer these three questions, you are not ready to agree a fixed price.
Use the answers to narrow the path. Stable processes and a need to retain history may favour brownfield conversion. A post-merger environment with inconsistent processes may point to greenfield or selective transition. A cloud build makes sense when the organization is ready to standardise. In each case, test how the proposed design affects business continuity and which custom code can be retired, rather than treating migration tooling as the main decision. A documented SAP migration methodology can help you check whether a bidder's proposed steps fit your chosen path, not just its preferred offering.
Choose a Delivery Model and Partner Mix
Fixed-price phases give you a set fee for defined scope and low to medium control. They work after discovery has gated the scope. They fail when requirements change after sign-off and every change becomes a dispute about what's included.
Time and materials bills day rates by role and gives you high control. It's the right model for uncertain design work. It's also the model that drifts when scope decisions are slow and nobody caps the hours at a gate.
Managed or outcome-based services charge a monthly run fee, sometimes tied to SLAs. They're suited to run support after go-live. The risk is quieter. Vendor incentives can drift from your outcomes if the SLA measures ticket closure rather than process health.
Blended onshore, nearshore and offshore delivery uses one blended rate and medium to high control. It works when solution architects and the design authority stay close to the business while build and regression testing move elsewhere. It breaks on time-zone handovers and knowledge loss when nobody owns the handover.
Questions that expose the risk
- Fixed price. Which deliverables change if a design decision reverses, and who pays?
- Time and materials. Which gate caps hours, and what happens when you hit it?
- Managed services. Which SLA credits apply, and who reviews them each month?
- Blended delivery. Who owns each interface across time zones, and where's the single defect log?
Require a written handover rhythm for blended teams. Daily cross-zone stand-ups, one shared defect log and a named owner for every interface aren't bureaucracy. They're how you stop a defect waiting twelve hours for the next shift.
Partner checklist before you score bids
Ask for named S/4HANA references in your industry and at your size, not logos. Contract for named senior roles with a continuity clause, not the pitch team. If a bidder claims an accelerator, ask for numbers from a previous migration and check whether your data profile matches the one it was built for. Accelerators don't shorten work if your systems don't resemble those they were built for.
Also require a documented delivery method plus clear knowledge-transfer and exit terms. Budget data migration as its own line rather than hiding it inside a blended rate. If a bid won't separate it, you can't govern it.
How to Run Discovery, Design and Governance
Early phases decide most of the later cost. Configuration is where money gets spent visibly, but scope, design and decision speed are where it's committed. Each phase below needs a gate with exit criteria you can measure.
The sequence and approval gates are shown in the diagram below.
Five steps with gates
- Name an executive sponsor and write decision rights. State who approves scope change, budget movement and new custom objects, and how many working days each decision may take. The common slip is a sponsor who attends the kickoff and never answers an escalation. The programme then makes decisions by delay.
- Confirm scope and the transformation approach. Use the migration path you've already chosen. List which legacy processes are in the first release and which wait. The slip here is scope described by module rather than by process, which hides gaps between finance, procurement and operations.
- Design the global template through fit-to-standard workshops. Run each core process against standard SAP, log every gap and reject any gap without a quantified business case. Workshops without a decision log get revisited for months. People remember the conversation differently and reopen settled points.
- Prototype the riskiest items early. Pick the three to five integrations with the largest data volume and build them first. Do the same for authorization roles that enforce segregation of duties. Waiting until build to test these turns an architecture problem into a schedule problem.
- Set stage-gate exit criteria in writing. A design gate might close only when open decisions fall below an agreed count and every process owner has signed the process map. Without that rule, gates become status meetings and unfinished design leaks into build.
What good governance looks like weekly
Keep a visible weekly decision log for the steering committee. Each entry needs an owner, a due date and the cost of not deciding. That last field changes behaviour. A decision that looks harmless in isolation looks different when the log shows it blocking three interfaces.
Practical rule: Reserve capacity for testing and data remediation from day one. Teams that borrow that capacity to protect design dates pay it back at cutover, with interest.
Governance also means limiting nonstandard customization unless a business case exists. That doesn't mean saying no to everything. It means the person requesting a custom object states the operational or compliance benefit, the owner accepts the maintenance cost, and the design authority records the decision. If nobody will own it after go-live, don't build it during the programme.
Finally, separate programme governance from project reporting. Reporting tells you tasks are complete. Governance tells you whether the design still fits the business, whether decisions are arriving on time and whether the next gate can legitimately be passed. SAP implementation services that blur those two give you green status reports right up to a red go-live.
Decide What to Keep, Fix or Retire in Custom Code
Standardizing a process can reduce maintenance, but retiring a customization without understanding its role can disrupt operations. Custom logic may enforce a tax rule, a clinical safety check or a regulator-facing approval that standard SAP cannot replace without business risk. Identify those controls before deciding what to remove.
Among SAP Americas users surveyed, 49% identified business-process change as a migration barrier, 44% cited customizations and 37% cited organizational resistance. Only 19% had fully completed their transition, according to reporting on SAP users yet to move from legacy ERP. Customizations were one of several barriers, not the only one. Their operational role needs to be assessed alongside user and process changes.
Custom-code outcomes and when to use them
| Outcome | Use when | Criteria to check | Relative effort |
|---|---|---|---|
| Retain in core | Standard tools cannot meet a compliance or safety need | Compliance exposure, business criticality | Low upfront, keep upgrade-safe |
| Remediate | The logic is needed but the code breaks on S/4HANA | Simplification fit, use of changed tables | Medium |
| Replace with standard | Standard functionality covers most of the need | Fit gap size, maintenance cost, user impact | Medium, change management heavy |
| Extend externally | The logic belongs outside the ERP core | Integration cost, latency, data ownership | Medium to high |
| Retire | Usage is low and the process is obsolete | Twelve-month usage, process owner sign-off | Low |
A working method you can audit
Export custom-object usage for the last twelve months. Score each object for business criticality, compliance exposure, maintenance cost, data quality and user impact. Assign an outcome from the table, then record the approver and the reason.
No executions during the review period makes an object a retirement candidate, not an automatic deletion. Check for year-end and regulatory runs that the usage window may have missed. A plant report used only for batch release, for example, may enforce a quality approval that auditors review. If so, preserve the control and remediate the code rather than retiring it.
A clean core approach for SAP keeps justified extensions, with a named owner and a maintenance path. It does not require an empty core. Record where each extension runs, what business control it supports and how changes will be managed, so the team can protect operational continuity through upgrades.
Assign one owner for each extension after go-live. Track performance and fund ongoing improvement so ownership does not lapse. Without that follow-through, workarounds can accumulate and custom code can become difficult to map or maintain. Decide before signing who will own each retained or remediated object, and include that work in the delivery and support responsibilities.
How to Migrate Data With Reconciliation Controls
Treat data migration as an engineering workstream that starts in month one, not a load task near the end. Late discovery of bad master data is expensive because it blocks testing, training and cutover at the same time.
Seven steps in order
- Profile source data and classify objects by business criticality.
- Define ownership, quality rules, retention and reconciliation controls for each object.
- Map legacy structures to the SAP target model.
- Cleanse, deduplicate, enrich and transform the data.
- Run iterative mock loads into a realistic target.
- Validate record counts, balances, referential integrity and process outcomes, not just load success.
- Freeze, cut over and monitor exceptions with named owners.
The benchmarks explain the urgency. Research summarized in a study of SAP data migration practice places extraction at approximately 18% to 24% of total project effort and broader data work at roughly 22% to 28% of the timeline. A separate study cited there reports more than 80% of data-migration projects run over schedule or budget, with average cost overruns of about 30%, and over 75% of respondents encounter data problems late in the lifecycle.
Reconciliation checks before cutover
| Object | Control | Threshold |
|---|---|---|
| General ledger balances | Balances match by company code and period after each mock load | Zero unexplained differences |
| Open receivables and payables | Count and value of open items per account | Zero unexplained differences; approved rounding tolerance only |
| Customer and vendor master | Record counts, duplicate checks and key references | Zero unexplained count differences; duplicates cleared before cutover |
| Inventory and stock | Quantity and value by plant and storage location | Business-approved tolerance per material class, written before the mock load |
| Open orders and deliveries | Count and status of open transactions | Zero orders lost or duplicated |
Baseline every migration object in the first month. Get business owners to sign transformation rules before the first mock load, and run at least three mock loads with reconciliation after each one. Tooling such as Pulse from Kagool can automate migration planning and validation, but tolerance decisions still belong to your business owners. A tool can flag a difference. It can't decide whether finance accepts it.
Use structured SAP data validation so each mock load produces evidence, not screenshots. You want repeatable counts, balances and exception lists that the same owner reviews each cycle.
If reconciliation depends on one person with a spreadsheet, you don't have a control. You have a dependency.
Protect Daily Operations Through Testing and Cutover
84% of organizations rated a smooth transition with minimal operational disruption as important or very important, according to SAPinsider's 2025 S/4HANA migration research. The same research found that 55% identified project duration as a major concern, up from 37% in 2024, while 62% cited project cost. Those figures describe priorities and concerns, not how projects fund continuity. Before signing, confirm the plan gives business-critical processes enough testing time and defines who can stop go-live.
Test depth and parallel running by process tier
| Process tier | Examples | Test approach | Parallel run |
|---|---|---|---|
| Tier 1, outage-critical | Order-to-cash, payroll, production orders, regulatory reports | End-to-end with volume tests across at least one full month-end | Yes, one or two closing cycles |
| Tier 2, business-critical | Procurement, inventory, month-end close | End-to-end for main variants, regression on key interfaces | Selective, reconciled outputs only |
| Tier 3, supporting | Standard reports, training catalogues, low-volume workflows | Smoke test and targeted regression | No, fix after go-live if needed |
Apply unit, end-to-end, regression, volume, security and user acceptance tests across the tiers. Set the depth by operational impact. Tier 1 failures can stop revenue, pay or compliance, so test volumes and run processes in parallel. Tier 3 workflows need targeted coverage; parallel operation may not justify the cost.
The embedded video is included as a resource; no claim is made here about what it demonstrates.
Cutover order and exit criteria
Use a fixed cutover sequence: freeze changes, run the final load, reconcile results against the data workstream's agreed thresholds, hold a go or no-go decision, then begin hypercare. Record the rollback decision point before the window opens, including its time window and named owner. If that owner cannot authorize rollback in time, the recovery plan is incomplete.
Agree go-live exit criteria before the final test cycle. Set the Tier 1 pass rate in advance, and reconcile interface message counts to their source. Assign decision authority for go-live and rollback, and confirm it is available throughout the cutover window. After launch, track service indicators for every Tier 1 process so faults surface in the first weeks, not at the next closing.
Confirm Readiness Before You Sign
S/4HANA projects average 30% longer than planned, and 65% of respondents report significant quality deficits, according to a study of SAP implementation success factors. Scope growth, weak project management, underestimated testing and migration, repeated design changes, and delayed decisions are recurring causes. Protecting operations and agreeing which custom code to retire deserve attention before migration tooling.
Use this checkpoint to identify gaps before signing. A pre-contract assessment can establish decisions and evidence; programme activities such as mock loads come later.
Before signing
- Sponsor and decision rights confirmed in writing, with decision deadlines.
- Migration path chosen, with the three scoping questions answered.
- Delivery model agreed, including the named senior team and exit terms.
- Custom-code decision log signed by process owners, identifying what to keep, fix, or retire.
- Data profiling complete, migration objects baselined, and reconciliation thresholds agreed in writing.
Before go-live and in the first 90 days
Agree the Tier 1 pass rate, complete role-based training, and rehearse cutover at least twice. Before cutover, require mock-load reconciliation against the agreed thresholds. Set up a four to eight week hypercare team with severity levels, named owners, and recovery procedures. Track help-desk volume, critical-process pass rates, and active-user behaviour weekly against the adoption plan.
Don't sign until each readiness gap has a priced fix in the plan. An unpriced gap becomes a change request.
Run a two-week readiness assessment against this list, internally or with an outside partner. If owners have not signed the custom-code decisions, or data profiling, migration scope, and reconciliation thresholds remain unresolved, price that discovery and its outputs before committing to implementation. Full mock-load reconciliation belongs in the programme, before cutover, not among the pre-signature gates.
Kagool delivers SAP implementation services across ECC to S/4HANA migration, data migration and validation, integration, testing, cutover, and managed support. Visit Kagool to discuss a readiness assessment focused on reconciliation controls, custom-code decisions, and operational continuity.
