Is SAP S/4HANA Public Cloud Edition the right fit for your business? Explore deployment options, financial considerations, readiness factors, and practical scenarios to make an informed decision.
What should an SAP partner deliver when an enterprise moves from ECC to S/4HANA?
More than a successful migration. The right partner will minimise transformation risk and protect what’s working while helping the enterprise build a S/4HANA environment for the future operating model.
An ECC to S/4HANA transformation can impact business processes, enterprise architecture, data, custom code, integrations, reporting, security and user roles. The scope will depend on the starting ECC landscape, the migration approach, and how the enterprise wants to run after go-live.
That is why partner selection matters. The partner may influence the migration strategy, target architecture, process design, custom-code remediation, data transition, integration landscape, testing, and future support. These decisions directly affect project scope, cost, business disruption, and the ability to maintain and extend the S/4HANA environment.
For US enterprises, the evaluation should also cover delivery capacity across business units and locations, governance, regulatory requirements, and long-term support. The partner should explain how its proposed approach fits the existing ECC landscape and supports the target S/4HANA operating model.
This guide examines the capabilities required to evaluate an SAP partner across migration strategy, architecture, business processes, data, clean core, integrations, delivery, commercial terms, and post-go-live support.
Short Answer: An SAP partner should deliver a complete transformation plan and the capabilities to execute it, from assessing the ECC landscape and selecting the migration approach to designing the S/4HANA target architecture, transforming business processes and data, managing custom code and integrations, and executing testing, cutover, and go-live.
For a US enterprise, the partner should also provide program governance, change management, multi-site delivery, and post-go-live support, with clear ownership, milestones, risks, and dependencies across each workstream.
Step 1. Define What the S/4HANA Transformation Should Change
The first partner-selection decision starts before the partner enters the picture. The enterprise needs a clear definition of the outcome it expects from S/4HANA. A technical conversion, ERP consolidation, process standardization, and finance transformation can all involve the same source system while requiring very different programs.
The intended outcome also determines how much change the organization needs to absorb. A company replacing an aging ECC platform may prioritize technical debt reduction and a clean core. A company consolidating several SAP instances may prioritize a global template and harmonized processes. An organization pursuing supply chain modernization may need substantial changes across planning, manufacturing, warehouse, and transportation processes.
What to define before partner selection
The current landscape provides the baseline for evaluating proposed approaches. The assessment should cover the SAP release, modules and add-ons, custom developments, integrations, data volumes, countries, sites, third-party applications, and reporting environment. Organizational structures and major business processes also belong in this assessment because they can affect migration scope and target design.
The transformation objectives should then translate into specific outcomes. For example, process standardization may mean reducing country-specific variants. Technical debt reduction may involve retiring obsolete custom code and replacing modifications with standard S/4HANA capabilities. ERP consolidation may require a common organizational structure across several existing systems.
The central question should remain concrete: What should materially change in the business and IT environment after the S/4HANA transformation? The answer gives potential partners a defined target against which their migration strategy, scope, timeline, and cost assumptions can be evaluated.
Step 2. Evaluate ECC-to-S/4HANA Migration Expertise
Migration expertise requires more than familiarity with SAP S/4HANA. The partner should demonstrate experience selecting and executing the migration approach that fits the source landscape, business objectives, data requirements, and appetite for process change.
Three main approaches require different planning decisions. A system conversion, often called a brownfield approach, converts an existing SAP ERP system to S/4HANA while retaining substantial elements of the existing configuration and processes.
A new implementation, commonly called greenfield, creates a new S/4HANA environment around redesigned processes and a new target configuration. Selective data transition moves selected data and organizational structures into a newly designed target environment.
How the partner should choose the migration approach
The partner should explain the criteria behind its recommendation. Those criteria can include the condition of the existing ECC system, the amount and complexity of custom code, organizational structure, data quality, process standardization goals, integration landscape, required historical data, and the desired target architecture.
Past projects provide useful evidence. Ask for examples involving similar ECC versions, business processes, industries, system complexity, and migration scenarios. The discussion should cover difficult parts of those projects as well. Examples include custom-code remediation, data quality issues, integration dependencies, downtime constraints, testing, and cutover.
A partner that recommends the same migration path for every ECC customer deserves closer scrutiny. The approach should follow the enterprise's transformation objectives and the characteristics of its existing landscape.
Step 3. Assess Business Transformation Expertise
S/4HANA can support changes to core business processes, yet the software alone does not redesign those processes. The partner needs business-process expertise alongside migration capabilities if the transformation includes operational change.
The assessment should cover the processes most affected by the transformation. Finance may involve changes to financial structures, reporting, and closing processes. Procurement and sales may require redesigned workflows and integration with external platforms. Manufacturing, warehouse, transportation, and supply chain programs, for example, can involve changes to planning, execution, inventory management, and operational data.
Look beyond technical migration
A partner should demonstrate how it uses Fit-to-Standard during process design. The team should assess the standard S/4HANA process first, identify legitimate business requirements, and reserve extensions for requirements that standard functionality cannot reasonably address. This approach can also support clean-core objectives by reducing unnecessary custom development.
Business transformation also requires a clear view of organizational impact. Changes to processes can affect roles, approvals, KPIs, reports, and daily work. The partner should define how business requirements translate into process designs and measurable outcomes, then support testing, training, and adoption around those changes.
A useful evaluation question is: Can the partner identify where the current ECC process creates unnecessary work and recommend a practical S/4HANA alternative? A strong answer should include specific examples of process analysis, redesign decisions, and measurable business outcomes from comparable programs.
Step 4. Evaluate S/4HANA Architecture Expertise
The target S/4HANA architecture should follow the enterprise’s operating model, integration requirements, security model, and long-term IT strategy. A partner should be able to compare the implications of on-premise, private cloud, and public cloud deployments rather than recommend an architecture without explaining the trade-offs.
The evaluation should cover the S/4HANA application layer as well as the surrounding architecture. For example, SAP BTP may support extensions and integrations outside the S/4HANA core. RISE with SAP can provide a managed cloud framework for S/4HANA. While the specific responsibilities and technical design still depend on the selected deployment model and contract.
What the architecture decision should cover
The partner should explain how the proposed architecture affects custom development, integrations, data management, security, system operations, scalability, upgrades, and total cost of ownership. These areas are connected. An integration design can affect upgrade effort. Extension choices can affect clean-core compliance. The deployment model can change infrastructure responsibilities and operational processes.
The discussion should also include the systems surrounding SAP. The S/4HANA integration architecture can be used by manufacturing, warehouse management, transportation, CRM, E-commerce, planning, analytics and third-party applications. The partner should map these dependencies and describe how these fit into the target landscape.
A useful evaluation question is: Why does this S/4HANA architecture fit the enterprise’s business and operating model? The answer should reference specific requirements, constraints, responsibilities, and expected costs.
Step 5. Assess Clean Core Expertise
An ECC-to-S/4HANA transformation provides an opportunity to reduce technical debt before it becomes part of the new environment. The partner should examine existing custom development and determine which components still serve a valid business requirement.
This assessment should cover custom ABAP, modifications, Z-programs, custom tables, workflows, reports, interfaces, and other enhancements. Each item needs a defined disposition based on its business purpose, technical condition, and compatibility with the target S/4HANA architecture.
How the partner should handle custom code
A practical assessment can classify existing developments into several paths: retire obsolete functionality, adopt standard S/4HANA capabilities, configure supported functionality, extend the application using appropriate extension options, or integrate external functionality where that approach fits the architecture.
Also, the partner should demonstrate experience with released APIs, in-app extensibility, and side-by-side extensions on SAP BTP. Knowing these approaches can reduce modifications to the S/4HANA core and make future upgrades easier to manage. The right choice depends on the requirement and the extension point available in S/4HANA.
The key question is: How will the partner prevent ECC technical debt from becoming S/4HANA technical debt? The answer should include a concrete remediation method, decision criteria, and examples from comparable transformations.
Step 6. Evaluate Data Migration Expertise
Data migration can determine whether business processes work correctly after the S/4HANA cutover. The partner should demonstrate control over the full data lifecycle, from discovery and profiling through transformation, migration, validation, and reconciliation.
The scope extends beyond master data. A typical transformation may involve Business Partners, materials, suppliers, customers, assets, inventory, open transactions, financial balances, and selected historical data. Each category has different quality issues, dependencies, and validation requirements.
How the partner should approach data
The partner should begin by establishing what data the target system actually requires. Data that has accumulated in ECC over many years may contain duplicates, obsolete records, inconsistent values, or structures that no longer fit the S/4HANA model. Migration should not automatically reproduce those conditions.
A sound approach assigns a clear treatment to each data set: migrate, transform, archive, or retire. Mapping rules should define how source data corresponds to target structures. Validation should compare migrated records with source data and business expectations. Financial data and open transactions require reconciliation against agreed control totals.
The partner should also demonstrate how it handles mock migrations. Repeated migration cycles can expose mapping, transformation, performance, and reconciliation issues before cutover. The final migration should follow a documented cutover plan with defined validation and sign-off criteria.
Step 7. Evaluate Integration Capabilities
An ECC-to-S/4HANA transformation can affect the interfaces that connect SAP with the rest of the enterprise. The partner should assess the existing integration landscape and determine how each connection fits into the target S/4HANA architecture.
The assessment should cover SAP and non-SAP systems, including SAP EWM, SAP TM, SAP CRM, MES, PLM, WMS, TMS, E-commerce platforms, banking and tax systems, legacy applications, and data platforms. The partner should also understand the business processes behind these connections because an interface can depend on specific transaction flows, master data, or business events.
Look at the integration architecture, not just the interfaces
The target design may use APIs, EDI, events, middleware, or SAP Integration Suite, depending on the systems and business requirements. The partner should explain why each integration pattern fits the relevant use case and how the connections will be monitored and supported after go-live.
The transformation also creates an opportunity to review interfaces that accumulated around the ECC environment over time. Some may support obsolete processes. Others may duplicate data flows or rely on point-to-point connections that create additional maintenance requirements. Rebuilding every existing interface can carry these dependencies into S/4HANA without addressing their original limitations.
A strong partner should have a defined method for analyzing interface dependencies and deciding which connections to retain, redesign, replace, or retire. The assessment should cover interface ownership, data flows, error handling, monitoring, security, and testing.
This leads to a more useful question for partner evaluation: How will the proposed integration architecture improve the way systems exchange data and support business processes after the S/4HANA transformation? The partner should answer with specific architectural decisions and examples from comparable projects.
Step 8. Evaluate Industry Expertise
Industry experience matters when S/4HANA changes processes that directly support physical operations. The partner needs to understand how SAP processes connect with the enterprise’s products, sites, suppliers, customers, assets, and regulatory requirements.
For example, a transformation of manufacturing could involve engineering, procurement, production, warehousing, delivery, and finance. A change to one process can affect material availability, production planning, inventory movements, delivery commitments and financial postings. Similar dependencies are found in automotive, aerospace and defence, pharmaceuticals and life sciences, logistics, retail and energy.
What comparable experience should cover
The relevant comparison goes beyond the industry label on a case study. Look for projects with similar process complexity, site structures, supply chains, regulatory requirements, and operating models. A partner that has implemented S/4HANA for a manufacturer, for example, should be able to explain its experience with production processes, plant-level operations, inventory management, and the integration of manufacturing systems.
The same principle applies across industries. A logistics company may have complex transportation and warehouse processes. A life sciences organization may have strict quality and traceability requirements. An energy company may operate large asset bases across multiple locations.
Ask the partner to show where its industry knowledge affected an actual design decision. A useful example should connect an industry-specific requirement with the resulting SAP process, architecture, integration, or data decision.
Step 9. Evaluate S/4HANA Deployment and Cloud Expertise
Cloud adoption can change the technical and operational model of an S/4HANA transformation. The partner should have practical experience with the deployment option under consideration and explain how that choice affects architecture, extensions, integrations, security, operations, and cost.
The relevant options can include SAP Cloud ERP Private, SAP Cloud ERP Private, on-premises S/4HANA, and hybrid landscapes. RISE with SAP can also form part of a cloud transformation. Hyperscaler infrastructure may be relevant to specific deployment scenarios and enterprise requirements.
Evaluate the operating model alongside the technology
Deployment decisions affect who manages infrastructure, upgrades, technical operations, security responsibilities, integrations, and extensions. They can also influence the degree of process standardization and the options available for customization.
The partner should explain the practical consequences of its recommendation:
- Which deployment model fits the enterprise’s requirements, and why?
- What changes in application management and infrastructure responsibilities?
- How will extensions and integrations work within the target architecture?
- What limitations or additional requirements will the model introduce?
- How will the cost structure change over the expected S/4HANA lifecycle?
The recommendation should follow the enterprise’s business and IT requirements. A partner’s cloud certifications or RISE experience alone do not establish that its preferred deployment model fits the transformation.
Step 10. Evaluate Finance and Business-Process Transformation Capability
Finance often sits at the center of an ECC-to-S/4HANA transformation because financial postings connect processes across the enterprise. The partner should understand how S/4HANA Finance changes the underlying data model and how those changes affect processes beyond the Finance organization.
Relevant experience can include the Universal Journal, financial data migration, Controlling, Asset Accounting, Group Reporting, financial close, and Treasury where applicable. The partner should also understand how Finance receives and generates data through procurement, sales, inventory, manufacturing, and supply chain processes.
Evaluate end-to-end process knowledge
Module expertise alone does not show how the target process will work. Consider a procure-to-pay process. A purchase order can affect inventory, goods receipt, invoice verification, accounts payable, and financial postings. A change to one stage can affect the next stages and the resulting financial data.
The same principle applies to order-to-cash and production. Sales orders, deliveries, goods movements, billing, production consumption, and financial postings form connected process flows. The partner should be able to map these dependencies and explain the target process across organizational and SAP functional boundaries.
A useful evaluation question is: Can the partner explain how a business transaction moves from the operational process to the final financial result? The answer should demonstrate process knowledge alongside S/4HANA Finance expertise.
Step 11. Evaluate Supply Chain, Manufacturing, and Logistics Expertise
For industrial companies, S/4HANA transformation can directly affect how materials are purchased, produced, stored, moved, and delivered. The partner should understand these operational dependencies before proposing changes to the SAP landscape.
Relevant expertise may include procurement, production planning, manufacturing, inventory management, quality management, asset management, SAP EWM, and SAP TM. The required scope depends on the company’s operating model and the systems already supporting these processes.
Evaluate the operational process chain
Manufacturing provides a useful example. A change to material planning can affect production orders, component availability, warehouse movements, capacity planning, quality processes, and delivery schedules. The resulting inventory and production transactions also feed Finance.
The same dependencies apply to logistics. Warehouse execution and transportation planning need to exchange the right information with S/4HANA and other systems. The partner should understand where S/4HANA ends and specialized applications such as EWM or TM begin, including how those systems exchange data and coordinate business processes.
This expertise matters when the S/4HANA program includes operational redesign. The partner should show relevant experience with similar plants, warehouses, supply chains, and manufacturing processes rather than relying only on generic ERP implementation experience.
For deeper guidance on these areas, explore our resources on SAP EWM, SAP TM, SAP Supply Chain, and SAP Manufacturing.
Step 12. Evaluate Data, Analytics, and Reporting Transformation
An S/4HANA transformation can also require changes to the reporting and analytics landscape. Legacy ECC reports may depend on data structures, extractors, custom programs, or separate data warehouses that will change during the transformation.
The partner should assess which reports support active business decisions and which can be retired. The same review should apply to duplicated reports, obsolete data extracts, and legacy warehouse structures. Rebuilding every existing report in the target environment can preserve unnecessary complexity and increase migration scope.
Assess the target analytics architecture
The partner should have relevant experience with SAP Analytics Cloud, SAP Datasphere, SAP Business Data Cloud, and data integration where these products fit the target architecture. The assessment should cover data sources, reporting requirements, security, data ownership, and the intended use of operational and analytical data.
Reporting requirements should also connect to the redesigned business processes. A KPI may need a different calculation after process changes. A report may depend on data that no longer exists in the same form. The partner should identify these dependencies before development begins.
The key question is specific: Which legacy analytics should be retired, redesigned, or rebuilt for the S/4HANA environment? The answer should come from a review of business requirements and the target data architecture.
.webp)
Step 13. Evaluate Testing Expertise
The testing should encompass the entire business process and the systems that support it. An SAP transaction can work fine in isolation while an integration, a downstream process, or financial posting fails. The partner should have a testing strategy to uncover these dependencies before production cutover.
Cover the full testing cycle
The testing scope should include several layers:
- Functional testing verifies individual S/4HANA processes and configurations.
- Integration testing verifies data exchange between SAP and non-SAP applications.
- End-to-end testing validates complete business flows, such as order, warehouse, transportation, delivery, billing, and Finance.
- Regression testing confirms that existing processes continue to work after changes.
- Performance and volume testing evaluates system behavior under expected transaction and data loads.
- User acceptance testing allows business users to validate processes against operational requirements.
- Cutover rehearsals validate the migration sequence, technical activities, business checks, and timing before go-live.
The partner should define test ownership, environments, test data, entry and exit criteria, defect management, and business sign-off. Automated testing can support repetitive regression scenarios where the process and tooling make automation practical.
Cutover rehearsals deserve particular attention for large ECC landscapes. They can expose migration timing issues, dependencies between technical activities, and gaps in business validation before the production event.
A strong testing approach should answer one practical question: How will the partner prove that the transformed business processes work across SAP, connected systems, and the migrated data before go-live?
Step 14. Evaluate Cutover and Go-Live Expertise
The S/4HANA solution may be well designed but still requires a controlled transition into production. Cutover combines data migration, integrations, security, business validation and technical operations in a tight window. The partner should have a documented plan that assigns ownership to each activity and defines the conditions for proceeding.
Examine the cutover plan
The plan should cover the final transaction freeze, data extraction and transformation, loading, validation, reconciliation, interface shutdown and restart, user access, and business sign-off. The sequence should also define dependencies and timing for each activity.
The final migration should follow the same controls established during mock cutovers. Financial balances and open items need reconciliation against agreed source-system figures. Critical interfaces need validation after restart. Business teams should confirm that essential processes work in the production environment before the system opens for normal operations.
The partner should also establish specific go/no-go criteria and contingency procedures. When the new system is receiving production data and transactions, a rollback plan may be technically impossible or impractical. The cutover plan should detail the conditions, the decision authority and the recovery actions for each critical failure scenario.
One question can reveal how seriously the partner has planned for failure: What happens if a critical reconciliation fails during cutover? The answer should identify who makes the decision, what evidence they review, how the issue is contained, and what happens to the go-live schedule.
Step 15. Evaluate Change Management
An S/4HANA transformation can change transaction flows, approvals, roles, reports, and daily work across the organization. Change management should address these operational changes alongside the technical implementation.
Assess how users will transition
The partner should identify affected stakeholder groups and map how their work will change. Finance, Procurement, Sales, Manufacturing, Warehouse, Logistics, and IT teams may have different training requirements and adoption risks.
The program should include role-based training, updated process documentation, communication, super-user programs, and support for the first weeks after go-live. Super-users can help validate processes before deployment and provide local support when users begin working in the new environment.
Adoption should also have measurable indicators. Examples include training completion, user participation in testing, support-ticket patterns, transaction errors, and use of redesigned processes. These measures can show where additional training or process support may be required.
The partner should also clarify its role after go-live. A defined support model can help business teams resolve process questions while the implementation team addresses defects and configuration issues.
Step 16. Evaluate Multi-Site and Rollout Experience
A multi-site S/4HANA program introduces additional coordination across plants, warehouses, distribution centers, legal entities, and acquired businesses. Each location may have different processes, data, integrations, users, and local requirements.
The partner should explain how it creates a common template and determines which elements remain consistent across sites. Local requirements should have a defined place in the design rather than becoming separate custom solutions for every location.
Site readiness also needs explicit criteria. These can include data quality, integrations, business-process validation, user training, infrastructure, security roles, and local business ownership. Rollout waves should use these criteria to determine when a site can move into production.
Experience from earlier waves should produce reusable migration assets, integration patterns, test cases, documentation, and training materials. The partner should be able to show how those assets reduce repeated work and shorten preparation for later waves.
Step 17. Evaluate the Actual Delivery Team
The people presented during partner selection may differ from the team assigned after contract signature. Enterprise buyers should establish who will hold key responsibilities during the transformation and how much senior involvement the program will receive.
Meet the people who will run the program
The core team may include a Program Director, Solution Architect, Migration Lead, Data Lead, Integration Lead, Finance Lead, Supply Chain Lead, Testing Lead, Cutover Lead, and Change Management Lead. The exact structure will depend on the program scope.
The evaluation should cover where these resources will work and how the delivery model will operate. US-based and onsite resources may support business workshops and local coordination. Nearshore or offshore teams can provide additional delivery capacity. The partner should explain responsibilities across locations, working hours, escalation paths, and handoffs.
Ask how much time the proposed senior specialists will actually spend on the program. Also ask how the partner handles staff changes during a multi-year transformation. Continuity matters because replacing key leads can require repeated knowledge transfer and slow decisions.
The most useful question is direct: Who will actually deliver the transformation after the contract is signed? The answer should name the proposed leads, their responsibilities, location, expected involvement, and process for replacing them if circumstances change.
Step 18. Assess US Delivery Capability
A US enterprise needs a delivery model that supports local business stakeholders while providing access to the wider project team. The partner should have clear accountability for US operations, including appropriate time-zone coverage, onsite availability, and experience working with US enterprise organizations.
Evaluate the delivery model
The delivery structure should also support companies operating across North America. Projects may involve teams and sites in the US, Canada, and Mexico, along with subsidiaries in other regions. The partner should explain how it coordinates requirements, governance, support, and project decisions across these locations.
A global delivery model can provide additional capacity and specialized expertise. The critical point lies in how responsibilities are divided. US-facing leadership should have authority over local delivery and escalation, while global teams should provide scalable technical and functional resources.
Ask how the partner handles working hours, onsite workshops, regional holidays, escalation, and post-go-live support. These details become especially relevant when business operations span several time zones.
Step 19. Evaluate the Implementation Methodology
The methodology should connect business process design with the technical work required to implement and deploy S/4HANA. A typical lifecycle can move through Assess → Explore → Design → Build → Migrate → Test → Deploy → Stabilize → Optimize, with activities overlapping as the program progresses.
Examine how the partner controls the program
The partner should explain how it manages governance, scope, decisions, risks, quality gates, and business participation throughout the lifecycle. Each phase should have defined outputs and criteria for moving forward.
Process, data, integration, testing, and change management also need to remain connected. For example, a process decision can change the required data mapping. An integration change can create additional test scenarios. A role redesign can require changes to training and security.
The methodology should make these dependencies visible rather than placing each discipline into an isolated workstream. Ask how unresolved decisions are escalated, how scope changes are approved, and how business owners participate in design and testing.
A useful evaluation point is the partner's ability to show how its methodology worked on a comparable ECC-to-S/4HANA program, including where the original plan changed and how those changes were controlled.
Step 20. Evaluate SAP BTP and Extension Strategy
SAP Business Technology Platform can support extensions, integrations, workflows, applications, APIs, automation, and other capabilities around S/4HANA. Its role should follow a defined architecture and business requirement.
Determine where BTP fits
The partner should distinguish between functionality that belongs in standard S/4HANA and requirements that justify an extension or external application. Side-by-side extensions on SAP BTP can keep additional application logic outside the S/4HANA core. SAP BTP can also provide integration and workflow capabilities where they fit the target architecture.
The evaluation should cover the full extension lifecycle. Ask how extensions will be designed, secured, tested, monitored, and maintained. The partner should also explain how released APIs and supported extension points will be used.
BTP should have a defined purpose within the architecture. Adding services without a clear business or technical requirement can increase the number of components the enterprise needs to operate and support.
The key question is: How will SAP BTP support new capabilities while keeping the S/4HANA core clean and maintainable?
Step 21. Evaluate References and Case Studies
References provide evidence of how a partner handled real transformation conditions. Generic SAP implementation examples provide limited insight into an ECC-to-S/4HANA program with comparable scope and complexity.
Ask for comparable projects
Look for references involving similar ECC versions, migration approaches, industries, user populations, site structures, data volumes, and US operations. A relevant case study should explain the project context and the partner's actual responsibilities.
During reference discussions, ask about:
- The migration approach and why it was selected
- Data migration and reconciliation
- Scope changes and unexpected costs
- Cutover and go-live
- The people who actually delivered the program
- Post-go-live support and unresolved issues.
The most useful references can describe difficult decisions as well as successful outcomes. Ask what changed during the project, where the original assumptions proved inaccurate, and how the partner responded.
A reference should also come from someone who had direct visibility into delivery. A senior business or IT stakeholder can provide more useful information about governance, communication, decision-making, and post-go-live performance than a generic project summary.
When several partners appear similar on paper, these conversations can reveal differences in execution that a proposal or capability presentation may not show.
Step 22. Evaluate Commercial and Contractual Terms
The proposal should make the full transformation scope visible. A low headline price can reflect activities that appear outside the initial estimate and become additional charges later.
Compare costs and responsibilities for assessment, implementation, migration, data cleansing, integrations, testing, training, change management, cutover, hypercare, travel, third-party services, cloud costs, and ongoing support.
The contract should also define assumptions, exclusions, payment milestones, change-request rates, deliverables, responsibilities, and transition terms. Pay particular attention to activities that depend on the enterprise providing data, resources, environments, or business decisions.
A useful comparison separates the initial implementation price from costs that may arise when project assumptions change. The commercial model should make those conditions explicit before the contract is signed.
Step 23. Evaluate Total Cost of Ownership
The initial implementation price represents only one part of the financial commitment. The total cost of ownership should include the work required to prepare, operate, maintain, and support the S/4HANA environment over its expected lifecycle.
Account for the full cost structure
Consider the cost of:
- Implementation: program management, functional design, configuration, development, and deployment.
- Data migration: profiling, cleansing, mapping, transformation, migration, and reconciliation.
- Custom-code remediation: analysis, retirement, redesign, and redevelopment of required functionality.
- Integration: interface redesign, development, testing, and monitoring.
- Testing: test environments, test execution, defect resolution, and regression testing.
- Change management: communications, training, documentation, and adoption support.
- Cloud or infrastructure: subscriptions, hosting, environments, connectivity, and related services.
- Training: role-based training and training-material development.
- Hypercare: post-go-live support and issue resolution.
- Ongoing support: application management, monitoring, maintenance, and future enhancements.
A partner offering the lowest initial price can produce higher costs later if the proposal leaves significant custom-code remediation, data preparation, testing, or integration work unresolved. TCO analysis should compare these downstream costs alongside the initial implementation estimate.
SAP Transformation Partner Evaluation Scorecard
A weighted scorecard can make partner evaluations more consistent across technical, business, delivery, and commercial criteria. The suggested weighting below provides a starting point and should reflect the priorities and risk profile of the specific transformation.
|
Evaluation Area |
Suggested Weight |
|
ECC-to-S/4HANA experience |
20% |
|
Business transformation expertise |
15% |
|
Architecture / deployment |
10% |
|
Data migration |
10% |
|
Clean Core / custom code |
10% |
|
Integration |
10% |
|
Industry expertise |
10% |
|
Delivery team |
5% |
|
Testing / cutover |
5% |
|
Commercial model |
5% |
Score each partner against the same evidence requirements. Adjust the weights when a program has specific priorities, such as complex manufacturing, multi-country deployment, extensive custom code, or a major cloud transition.
Red Flags When Choosing an S/4HANA Transformation Partner
“We can convert everything”
A partner that presents conversion as the default solution may give insufficient attention to obsolete processes, custom code, poor-quality data, or target-state requirements. Ask what the partner would retire, redesign, or replace before migration.
“Our migration approach is already decided”
A brownfield, greenfield, or selective data transition approach should follow a landscape assessment and defined business objectives. A recommendation made before that analysis leaves little room for evidence-based decision-making.
“We’ll recreate the customizations in S/4HANA”
Carrying ECC modifications, Z-programs, custom tables, and legacy workflows forward without a structured assessment can transfer technical debt into the target environment. The partner should have clear criteria for retiring, standardizing, configuring, extending, or replacing existing functionality.
“Data migration is an IT workstream”
Business teams need to define which data remains relevant and validate the results. A partner should have clear ownership, mapping rules, data-quality controls, and reconciliation criteria for critical business data.
“We’ll take care of the integrations later”
Integration dependencies can affect process design, testing, and cutover. Leaving the integration landscape until late in the program can create avoidable dependencies and compressed testing windows.
“The scope is the technical conversion”
A partner focused primarily on moving the system may overlook process redesign, role changes, reporting, training, and adoption. Ask how business transformation activities fit into the proposed program.
“The team you meet now may change later”
A proposal can feature senior specialists who have limited involvement after contract signature. The partner should identify the people responsible for delivery, their expected involvement, and the process for managing staff changes.
“We can deliver it for this price”
An unusually low proposal can result from narrow scope assumptions or exclusions for data cleansing, testing, integrations, cutover, training, or post-go-live support. Compare the assumptions and deliverables behind each price before comparing the numbers.
“Post-go-live support is a separate conversation”
The first weeks after deployment can expose process, integration, data, and performance issues that were difficult to reproduce before production. The contract should define the hypercare model, support responsibilities, response expectations, and transition to ongoing application support.
What Makes a Strong ECC-to-S/4HANA Transformation Partner?
A strong partner should cover the full transformation lifecycle. Technical migration expertise provides the foundation, while business, architecture, data, integration, and delivery capabilities determine how the target environment will operate.
- Migration expertise — Can plan and execute system conversion, new implementation, or selective data transition based on the actual landscape.
- Business transformation — Can redesign processes, apply Fit-to-Standard, and challenge legacy requirements that no longer serve the business.
- Architecture — Can design an S/4HANA target architecture across deployment, integration, extensions, security, and operations.
- Data — Can assess, cleanse, transform, migrate, validate, and reconcile business-critical data.
- Integration — Can design connectivity between S/4HANA, SAP applications, and non-SAP systems.
- Change management — Can prepare users for new processes, roles, and workflows and support adoption after go-live.
- Delivery — Can manage governance, testing, cutover, resources, risks, and decisions across a complex enterprise program.
- Long-term support — Can provide application support and help manage the S/4HANA environment after stabilization.
LeverX brings these capabilities together for ECC-to-S/4HANA transformations
LeverX supports SAP transformation programs for US enterprises, bringing together SAP consulting, assessment, architecture, migration, implementation, integration, data transformation, and post-go-live support. The team can assess the current ECC landscape, evaluate migration scenarios, define the target S/4HANA architecture, plan data and integration changes, and build a transformation roadmap aligned with business and technical requirements.
Key engagement formats include:
- SAP transformation assessment — evaluate the current ECC landscape, readiness, risks, and transformation options.
- Migration strategy and roadmap — define the transformation approach, priorities, phases, and target outcomes.
- S/4HANA architecture consulting — design the target architecture, deployment model, integration landscape, and extension strategy.
- Data migration and transformation — plan and execute data cleansing, mapping, migration, and validation.
- Business process transformation — align S/4HANA capabilities with finance, supply chain, manufacturing, logistics, and other business processes.
- Integration and SAP BTP — modernize integrations and define approaches for extensions and side-by-side development.
- Implementation and rollout — support S/4HANA implementation, testing, cutover, go-live, and multi-site deployment.
- Change management and adoption — support organizational readiness, user adoption, and transition to new processes.
- Post-go-live support and optimization — continue improving the S/4HANA environment after deployment.
Book a strategy session with LeverX to discuss your current ECC landscape, transformation objectives, and potential next steps toward S/4HANA.
FAQ
What is the distinction between a SAP migration partner and a SAP transformation partner?
The SAP migration partner’s main goal is to migrate the existing ERP environment to S/4HANA. A transformation partner for SAP also handles process redesign, architecture, data, integrations, custom code, user adoption, and target operating model.
Should I choose a large SAP system integrator or a specialist partner?
The choice should depend on the program’s scope, required expertise, delivery model, and level of senior involvement. A large system integrator may provide extensive global capacity, while a specialist partner may offer deeper expertise in specific SAP domains or industries. Compare the capabilities and proposed delivery team against the actual program requirements.
How much does an ECC-to-S/4HANA transformation cost?
For the U.S. market, indicative planning ranges are:
- $750K–$1.5M — smaller / lower-complexity conversion
- $1.5M–$4M — mid-market brownfield migration
- $4M–$10M+ — enterprise S/4HANA transformation
- $10M–$25M+ — large global transformation
These are planning ranges, not fixed implementation quotes. Actual costs depend on the scope and complexity of the transformation, including the migration approach, custom code, integrations, data, business-process changes, number of entities or countries, and deployment model.
How long does the ECC to S/4HANA migration take?
Typical planning timelines are:
- 6–10 months — standard single-country Brownfield conversion
- 12–18 months — medium-sized enterprise migration
- 18–24 months — large, global enterprise migration
The actual timeline depends on system complexity, custom code, data volume and quality, integrations, business-process changes, and the number of entities or countries involved.
Disclaimer: The information, cost and timeline ranges, and recommendations presented in this guide are provided for general informational and planning purposes only. Actual S/4HANA transformation costs, timelines, scope, and outcomes vary depending on an organization's SAP landscape, business requirements, technical environment, migration approach, geographic footprint, and other project-specific factors. The figures provided are indicative estimates and should not be considered fixed quotes, guarantees, or project commitments. A detailed assessment of the current SAP environment is required to develop a project-specific transformation plan, cost estimate, and timeline.
