SAP S/4HANA implementations take longer and cost more than planned often enough to make delivery controls part of the business case. An independent report on a 2025 Horváth study found that projects took 30% longer than initially anticipated on average, while 55% of leaders whose migrations were near completion reported budget overruns. For teams approving an SAP HANA implementation, these findings make a fixed go-live date a weak starting point.
Set evidence-based gates before committing further budget. Each gate should test whether the business case still holds, whether data and scope are understood, and whether the delivery model can meet the required quality. If evidence is incomplete, resolve the gap before advancing. This approach exposes schedule, budget, and quality risks early, when teams can still adjust scope or resources rather than face them during cutover.
Table of Contents
- Assessing Readiness and Business Case Before You Approve
- Sizing Memory and Architecture for SAP HANA
- Choosing a Migration Path and Delivery Partner
- Engineering Data Migration Through Three Test Cycles
- Freezing Scope and Running a Controlled Cutover
- Operating Model and Performance Tuning After Go-Live
- Taking the Next Step With a Readiness Review
Assessing Readiness and Business Case Before You Approve
Approval should depend on evidence that the organization can deliver the migration and realize its expected benefits. Cost, project duration, and the complexity of the existing SAP environment are common barriers. Those risks are connected: complex systems require more discovery and integration work, which can extend delivery and delay benefits.
That schedule pressure has financial and quality consequences. The Horváth study cited earlier found that implementations took longer than planned on average, with budget overruns and missed quality targets also reported. Treat those outcomes as risks to test against your own scope, dependencies, and delivery capacity, not as a forecast for every program.
| Migration barrier cited | Share of organizations |
|---|---|
| Project cost | 62% |
| Project duration | 55% |
| Existing SAP landscape complexity | 43% |
Make the economics decision-ready
Calculate the cost of delay in business terms. Identify the operational improvements, reporting changes, and support savings that depend on the migration. Then show how postponing those benefits changes the business case. Document the assumptions, including when benefits begin and which delivery milestones they depend on. Leaders should be able to challenge the inputs and see what would change the result.
Use a guide to calculating the ROI of an SAP S/4HANA migration to structure the assumptions and test whether projected returns justify the investment.
Set a contingency threshold before approval. Specify which cost or schedule variances require a steering decision, who can authorize scope changes, and what evidence releases the next tranche of funding. A workstream's claim that it is “mostly complete” is not enough. Tie funding to deliverables that leaders can inspect, such as an agreed scope, reviewed dependency map, or completed readiness assessment. That makes the approval gate meaningful and gives the team a way to address slippage before it affects the whole program.
Set the first go-or-no-go test
Before authorizing full delivery, require a readiness pack that establishes whether the work is defined and owned:
- Data quality: Profile priority master and transactional data, record known defects, name business owners, and agree a remediation approach.
- Custom code: Inventory significant objects and record whether each will be retired, replaced, or remediated.
- Integrations: Map connected systems, identify owners and dependencies, and agree how critical interfaces will be tested.
- Testing: Define coverage and exit criteria for end-to-end processes, data reconciliation, and user acceptance.
- Business readiness: Name process owners and decision-makers, and document role-based training and operational support arrangements.
These checks also expose operating-model gaps. If business owners lack time to resolve data issues or approve process decisions, the schedule is already at risk, regardless of the technical design. Make those responsibilities explicit before funding delivery.
If the team cannot produce this evidence, approve discovery and planning rather than an assumed delivery schedule. A credible go decision rests on readiness, not optimism.
Sizing Memory and Architecture for SAP HANA
Memory sizing is a workload decision, not a hardware guess. Start with the source system's actual database footprint and table distribution. Then account for expected growth, retention choices, compression assumptions, and the temporary memory required during loads and restarts. A design based only on steady-state demand can fail during migration or peak processing, putting the schedule at risk.
Separate the capacity for routine operations from what data loads, transformations, recovery, and concurrent business activity require. Have the infrastructure team document its assumptions and test them against observed workloads. For cloud hosting, confirm the certified configuration and practical limits for scaling, storage, and replication before committing to an architecture. Those choices affect both the budget and the recovery options available to operations.
Historical infrastructure milestones show how far HANA deployments expanded. AWS announced a 2-terabyte-memory instance in May 2016, and SAP certified scale-out HANA clusters reaching 7 nodes and 14 terabytes of RAM in August 2016 (AWS's report on SAP certifications and benchmark results). These figures are historical reference points, not recommendations for a current system. Use workload evidence, not past capacity records, to set today's design.
Plan for throughput, not just capacity
A 2017 SAP-certified SAP Business Warehouse on HANA benchmark reported a dataset of 46.8 billion initial records and a total data-load and transformation runtime of 559,827 seconds, or about 155.5 hours (AWS's benchmark report). That result does not predict another deployment's performance. It does show why load architecture, sequencing, transformation logic, and available downtime must be treated as design decisions.
Model when data will be extracted, transformed, loaded, and reconciled. Test whether heavy jobs compete with business workloads, and identify tables or objects that can run in parallel without breaking dependencies. Adequate memory alone will not keep a migration within its cutover window if the load sequence is inefficient. Validate the plan in test cycles, then use measured runtimes to refine the schedule.
Size environments for their purpose
Production specifications rarely make sense for every environment. A sandbox can support design exploration with a limited data set. Quality needs representative data and integrations for meaningful testing. Production must meet peak workload, recovery, failover, and agreed business operating requirements.
For each environment, document data volume, expected concurrency, refresh method, and downtime tolerance. Use those requirements to choose scale-up or scale-out and allocate capacity. This evidence-based gate helps avoid unnecessary non-production spend without weakening test coverage or leaving production exposed to workload and recovery risks.
Choosing a Migration Path and Delivery Partner
Migration paths are trade-offs, not labels for a preferred technology. Greenfield starts with a new design and limits legacy carryover. It's a strong option when the business wants substantial process redesign, but that ambition brings more change decisions and greater demands on business participation.
Brownfield converts the existing system and retains more of its configuration, history, and custom code. It can reduce process disruption, but it can also carry technical debt into the new environment. A conversion isn't a shortcut around decisions about which custom processes still earn their keep.
Selective data transition occupies the space between them. The organization chooses which data and history to move, rather than treating the entire legacy environment as either untouchable or disposable. That can be useful when the business needs selected history for reporting but wants to avoid carrying forward every old record and process.
| Decision factor | Greenfield | Brownfield | Selective data transition |
|---|---|---|---|
| Process design | Broad redesign opportunity | Existing processes largely retained | Redesign where selected |
| History | Retain what the new design requires | More legacy history carried forward | Choose required history |
| Custom code | Reassess and rebuild only justified needs | More remediation and retirement decisions | Assess by process and data scope |
| Main trade-off | Greater business change effort | Technical debt may persist | More selective mapping and validation |
Choose against business conditions
Start with the volume and criticality of custom code. If many custom objects support obsolete workarounds, carrying them forward may preserve cost without preserving value. Then establish which years of history the business needs in the target system, and which can remain accessible through an archive or analytics platform.
Company-code complexity and organizational change matter, too. A merger, divestment, or planned operating-model change can make a single, broad conversion a poor fit. In those cases, teams should test whether selective transition better matches the destination design and reporting needs.
Practical rule: Choose the path that fits the business change the organization is prepared to make, not the path that looks simplest in a technical plan.
A delivery partner should be able to explain how it will plan migration, validate results, and transfer capability to internal teams, as well as how it will configure the system. Kagool's Pulse supports SAP data-migration planning, execution, and validation; Velocity provides no-code SAP data ingestion to Azure for analytics; and its Build Factory Model supports repeatable delivery. Kagool also describes a compliance-aligned extraction approach in response to RFC-based methods being deprecated, with delivery teams distributed across onshore, nearshore, and offshore locations.
Evaluate partners on named responsibilities, decision rights, and how they'll work with your staff. This guide to choosing an SAP implementation partner can help frame those questions. A partner can provide specialist capacity, but the business must retain ownership of process decisions, data acceptance, and scope.
Engineering Data Migration Through Three Test Cycles
Treat migration as an engineered workstream, not a cutover task. Its quality affects the schedule, budget, and confidence in business results. Start with an inventory of company codes, plants, customers, suppliers, materials, business partners, open items, inventory, orders, and any history needed for operations or reporting.
Map dependencies before building transformation rules. Suppliers and business partners may need to load before related purchasing records. Inventory, open items, and orders can also dictate load sequence and reconciliation. Miss these relationships, and later cycles absorb rework that could have been caught during design.
Profile data for completeness, uniqueness, referential integrity, and code-value compatibility. The migration evidence reports that master-data inconsistencies accounted for 47% of migration issues. It also reports that completing at least three full test cycles was associated with 87% fewer production migration issues than completing only one or two (migration evidence report). Use these findings to justify planned test effort, not to promise that repetition alone will prevent defects.
Give each cycle a clear proof obligation
Cycle 1 proves the pipeline. Test connectivity, extraction, transformation execution, technical load behavior, and initial error handling. Find structural problems while the team still has room to change its approach.
Cycle 2 proves the data and rules. Test cleansing, mapping, reconciliation, and business-process outcomes. Business owners should review exceptions and confirm that transformation rules reflect the target organization's operations. Unresolved mapping decisions here can turn into schedule and quality risks later.
Cycle 3 proves the cutover. Run a production-scale rehearsal of the agreed load sequence, expected downtime, rollback, authorizations, interfaces, and operational controls. Record elapsed time and open defects. A critical step that still relies on manual improvisation is a readiness gap, not a minor rehearsal issue.
A technically complete load is not an accepted load. Reconcile record counts, monetary balances, inventory quantities, open-document status, and downstream analytics. Process owners must confirm that results make business sense. IT should not certify its own data without business review.
Validate the target S/4HANA data model and interfaces directly. ECC table structures and validation logic may not carry across unchanged. Each cycle should leave a defect log, named owners, retest evidence, and a documented decision on whether the next cycle can start. That evidence gives delivery leads a basis to protect schedule and budget without lowering data-quality standards.
Freezing Scope and Running a Controlled Cutover
A late change can add more than build work. It may alter data mappings, integrations, user procedures, and test evidence, turning a small request into a cutover risk. Require an impact assessment before approving changes, especially once final testing begins.
Run the program through evidence-based gates, each with an accountable approver and a written decision. Confirm the business case and scope, readiness and process fit, design choices, data preparation, approved configuration, integrated testing, role-based training, cutover rehearsal, and stabilization. At each gate, record what passed, what remains open, and which risks the business has accepted. This makes schedule, budget, and quality exposure visible before they converge at go-live.
A University of Kansas review of 20 SAP implementations identified sustained executive ownership, capable teams, process design, testing, and end-user training as strong success factors. It also reported that more than 30% of ERP projects were perceived to fail because of inadequate project planning (University of Kansas review of SAP implementations).
Make design authority real
Approve a customization only when it has a quantified business benefit, a lifecycle owner, test evidence, and an assessment of upgrade impact. If the sponsor cannot identify the business outcome that requires the change, use standard functionality or reconsider the process.
Scope control has direct delivery consequences. A survey of 105 companies found that 36% believed their SAP project stayed on its original plan, 52% reported budget overruns, and 48% said business objectives weren't achieved. These results were reported in the same University of Kansas review of SAP implementations. Keep the evidence attached to the approval decision, rather than treating scope review as paperwork.
Use the cutover rehearsal to test decisions, not just task order. For example, if a third-party interface finishes later than the runbook allows, follow an agreed decision point: wait within the defined window, invoke rollback criteria, or proceed only after the business accepts the documented impact. Without a tested decision path, teams negotiate while systems are unavailable.
Set a scope freeze date before final testing and define how exceptions are reviewed. The freeze should still allow defect correction, but new business changes need an impact assessment and approval before entering the release.
After go-live, assign named owners to incidents, data reconciliation, process questions, and unresolved defects. Give the business clear authority for operational decisions, and hand over runbooks and evidence before closing the project.
Operating Model and Performance Tuning After Go-Live
A clean core changes where work happens. When custom logic moves into extensions or connected applications, the organization still needs someone to own its business rules, interfaces, data products, and release decisions. Without that ownership, technical debt may shrink inside the ERP while operational complexity grows around it.
SAPinsider's 2025 benchmark found 68% of organizations prefer specialized consultants, while reliance on internal teams fell from 24% in 2022 to 10% in 2025. In a related 2025 ASUG-reported survey, business-process change was a barrier for 49% of respondents, customizations for 44%, and 83% of stakeholders didn't fully understand SAP's latest migration policies and deadlines (SAPinsider's detailed migration findings). The figures point to an operating-model problem as well as a technical one: outside expertise may be needed, but internal teams must retain enough knowledge to govern the system.
Assign ownership beyond the core
A durable model names owners for data stewardship, extension governance, release management, role design, segregation of duties, and user adoption. Process owners should also review how work flows across SAP and connected applications, using process analysis to identify bottlenecks and control gaps. Partners can help establish these practices, but capability transfer should be part of the service, not an informal promise.
Performance tuning belongs in the same operating model because it affects business processes and system capacity. Operations teams should monitor memory consumption and expensive SQL statements, review workload management, assess partitioning for very large tables, and check delta merge behavior after high-volume loads. They should also connect technical findings to the workload involved, so tuning decisions don't optimize one process at the expense of another.
The key is to define an owner and escalation path for each recurring issue. If an integration causes a performance problem, infrastructure teams, application owners, and process leads need a shared route to diagnose it. If an extension changes a business rule, the data and process owners must know how the change is tested and released.
A guide to SAP system performance tuning can support that discussion. Clean core is a design choice, not a complete operating model. It can reduce customization in the ERP while shifting complexity to integrations, extensions, and governance. The organization needs both the architecture and the people who can operate it.
Taking the Next Step With a Readiness Review
A short readiness review can turn broad concerns into decisions the steering committee can act on. Start by assigning business and technical owners, then work through the evidence together rather than treating discovery as an IT-only exercise.
Over a two-week review, produce four practical outputs:
- System inventory: Count and classify custom objects and interfaces, with an owner and an initial keep, replace, or retire decision for each significant item.
- Data-quality baseline: Profile priority master data and open transactions for completeness, duplicates, referential integrity, and code-value consistency.
- Scope decision log: List unresolved decisions about process changes, custom code, required history, integrations, and any organizational changes that could affect the target design.
- Initial go-or-no-go criteria: Agree on the evidence required for data quality, integration readiness, and business readiness before the program moves into delivery.
Estimate the cost of delay using business assumptions the finance and process owners can challenge. Record uncertainty rather than disguising it as a firm forecast. If a key assumption is unknown, assign someone to resolve it before the steering committee treats the estimate as a commitment.
Kagool can support an SAP data-migration readiness review, including planning and validation through Pulse, and provide training or mentoring to build internal capability for the operating model. Start by assembling your system inventory and naming the business owners who'll sign off the data and process decisions.
Kagool supports SAP S/4HANA readiness, migration planning, data validation, integration, and managed services for complex enterprise programs. Visit Kagool to discuss a readiness review and identify the evidence your team needs before committing to a go-live date.
