20 Questions To Ask an SAP Implementation Partner Before You Sign

Automotive supply chain disruptions can delay production and erode margins. The article explains where coordination fails and how SAP helps reduce the resulting costs.

Choosing an SAP implementation partner becomes difficult when every shortlist looks roughly the same. The candidates have SAP experience, customer references, certified consultants, and a methodology slide that promises predictable delivery.

The differences become clearer when you stop asking what a partner can do and start asking for evidence of what it has done — and what it is prepared to commit to for your project.

A useful answer should contain something you can verify: a named project, a date, a number, a current credential, a project artifact, or a contractual commitment. That principle applies across the engagement, from implementation methodology and SAP S/4HANA transition strategy to data migration, governance, pricing, staffing, and post-go-live support.

For organizations still running SAP ERP 6.0, timing adds urgency. SAP's published maintenance strategy provides mainstream maintenance through the end of 2027 for SAP ERP 6.0 Enhancement Packages 6, 7, and 8, followed by optional extended maintenance through the end of 2030. SAP ERP 6.0, without an enhancement package or with Enhancement Packages 1–5, left mainstream maintenance at the end of 2025 and entered customer-specific maintenance. 

Partner experience also matters for organizations planning the transition. In SAPinsider's 2025 Deployment Approaches to SAP S/4HANA research, based on a survey of 156 members of its community, 83% identified a proven partner with SAP S/4HANA implementation experience as a requirement for their deployment strategy.

Use the following 20 questions in an RFP, vendor workshop, or final partner-selection meeting. They apply both to new SAP implementations and, where relevant, to an SAP S/4HANA migration from an existing SAP ERP landscape.

Questions 1–7: Methodology, Architecture, and Technical Delivery

A methodology matters only when it translates into concrete decisions, deliverables, responsibilities, and quality gates. This part of the evaluation should establish how the partner intends to move from the current landscape to a working production system — and how it will manage technical risks along the way.

1. Which of your recent SAP implementations most resembles ours, and what changed between the original plan and go-live?

You are looking for a comparable delivery record, not the partner's most impressive case study.

Recent adoption data shows why the details behind an implementation reference matter. In SAPinsider's 2026 ERP Migration and Transformation benchmark research, based on 296 community respondents, 55% reported that they had completed an SAP S/4HANA or SAP S/4HANA Cloud deployment, but only 34% said they had completed the overall transition. SAPinsider notes that a deployment may cover only one ERP instance, a pilot, or a proof of concept, while other legacy systems remain in operation.

A useful answer should describe the customer's industry, system landscape, geographic scope, implemented modules or solutions, project approach, approximate team size, and actual timeline. Then ask what changed after the project began: scope, schedule, resources, technical assumptions, or business requirements.

The important part is not whether everything went according to plan. It is whether the partner can explain what changed, why, and how the team responded.

Ask to see: A relevant case study, reference architecture, anonymized project plan, or customer reference that supports the example.

2. Which SAP Activate roadmap will you use, and which methodology activities, deliverables, and quality gates apply to our project?

SAP Activate is structured around the Discover, Prepare, Explore, Realize, Deploy, and Run phases, but the detailed activities and deliverables differ depending on the solution and implementation approach. Where the engagement is part of a RISE with SAP journey to SAP Cloud ERP Private, ask how the RISE with SAP Methodology augments the selected SAP Activate roadmap, including the additional activities and quality gates that apply.

Ask the partner to map its proposal to the relevant methodology rather than simply saying that it "follows SAP Activate." The Explore phase deserves particular attention because this is where fit-to-standard workshops, requirements, process gaps, extensions, integrations, and other design decisions become clearer. Ask what the partner expects to resolve during Explore and what must be approved before Realize begins.

Ask to see: The proposed roadmap, applicable methodology activities, phase deliverables, quality gates, acceptance criteria, and responsibility matrix for your project.

3. Which target deployment model and transition approach do you recommend, and what will you assess before committing to them?

The target deployment model and the transition approach are related but separate decisions. For an existing SAP ERP customer moving to SAP S/4HANA, first establish the appropriate target deployment model. SAP S/4HANA Cloud Public Edition, a foundational application of SAP Cloud ERP, supports New Implementation. SAP S/4HANA Cloud Private Edition, the core ERP application within SAP Cloud ERP Private, and on-premises SAP S/4HANA can support New Implementation and System Conversion, as well as Selective Data Transition, where the source landscape and selected migration approach meet the applicable requirements.

If a proposal uses terms such as greenfield, brownfield, or bluefield, ask the partner to map those labels to the actual transition approach being proposed. The recommendation should follow an assessment of your landscape rather than precede it. Ask which criteria drive the deployment choice and which drive the transition choice. Relevant factors can include process redesign requirements, custom code, data quality and volume, historical data requirements, integrations, organizational changes, downtime constraints, and requirements for the target operating model.

Ask to see: The deployment and transition assessment methodology, decision criteria, major assumptions, and deliverables that will support both recommendations.

4. How will you decide what to standardize, retire, rebuild, or extend while maintaining a clean core?

Clean Core does not mean eliminating every extension or moving every customization outside the SAP system. SAP supports different extensibility approaches depending on the solution and use case, including key-user extensibility, developer extensibility, and side-by-side extensions. The important question is how the partner decides among standard functionality, supported extensibility, process redesign, and retirement of legacy custom code.

Ask how existing custom developments will be assessed and who has the authority to approve exceptions to the agreed clean core principles. A recommendation to retain significant legacy custom code should also explain the expected effect on upgrades, support effort, and future technical debt.

Ask to see: The custom-code assessment approach, extension decision framework, architecture principles, and exception-governance process.

5. What data will migrate, who owns its quality, and how will you prove that the migration is complete?

Data migration should have its own workstream and acceptance criteria. Ask the partner to define which master data, open transactional data, open items, balances, and other required data are in scope and how historical information that will not be migrated will remain accessible. The available migration scope depends on the target and transition approach. For example, in an SAP Cloud ERP New Implementation, closed historical transactional data cannot be migrated through the SAP S/4HANA migration cockpit, although certain historical balances can be migrated.

Then establish ownership. The implementation partner can provide tools, mappings, transformation logic, and migration execution, but business teams are usually essential for cleansing, validation, and approval. The partner should also explain how many mock migration cycles are planned, how reconciliation will work, what error thresholds are acceptable, and who signs off before cutover.

Ask to see: The migration strategy, object inventory, data-ownership matrix, mock-load schedule, reconciliation approach, historical-data access approach, and acceptance criteria.

6. Which integrations are in scope, who owns each interface, and how will you test the complete business process?

An SAP implementation rarely operates in isolation. Interfaces may connect SAP with CRM, warehouse, manufacturing, banking, tax, e-commerce, procurement, HR, analytics, logistics, or industry-specific systems.

ASUG and SAP integration research published in 2026, based on responses collected in November 2025, found that 88% of respondents were somewhat to extremely involved in integration projects and organizations integrated with 18 applications on average. The same research found that 43% cited a lack of internal skills or resources as an integration deployment challenge.

Ask for an integration inventory rather than a general statement about integration capability. Each interface should have an owner, source and target systems, technology, data direction, frequency, dependencies, testing approach, and failure-handling process. The partner should also explain how interfaces will be monitored after go-live and who owns incidents that cross system or vendor boundaries.

Ask to see: The interface inventory, integration architecture, ownership matrix, monitoring approach, and an example of an end-to-end integration test.

7. What is your testing, cutover, go/no-go, and fallback or recovery approach?

Testing is broader than a quality gate between Realize and Deploy. Ask how the partner plans unit testing, system integration testing, user acceptance testing, regression testing, and any required performance or security testing. Establish who prepares the test data, who owns business-process validation, and what defect thresholds block progression.

Cutover should be equally explicit. Ask about rehearsal cycles, final migration, interface activation, business validation, expected downtime, go/no-go authority, the point of no return, and the applicable rollback, fallback, or recovery procedure. The partner should be able to explain both the process and the decision rights behind it.

Ask to see: The test strategy, defect-severity model, cutover plan, rehearsal schedule, go/no-go checklist, point-of-no-return criteria, and rollback, fallback, or recovery plan.

Questions 8–10: SAP Credentials, Security, and Delivery Controls

Company logos and certification counts are easy to display. What matters is whether the credentials are current, relevant to the solutions you are buying, and connected to the people who will actually deliver the work.

8. Which current SAP competencies and specializations directly match our project scope?

SAP partner competencies are solution-specific and can be achieved at the Essential, Advanced, or Expert level, with specializations providing more detailed evidence in particular areas.

Ask the partner to open SAP Partner Finder during the evaluation and compare its current profile with the capabilities claimed in the proposal. Do not treat a broad SAP partnership status as evidence of equal depth across every SAP solution. Match the partner's recognized competencies to the solutions and services actually in scope.

Ask to see: The current SAP Partner Finder profile and the competencies and specializations relevant to your project.

9. Which consultants assigned to our project hold current SAP Certifications relevant to their roles?

A company-wide certification count does not tell you who will work on your implementation. Ask for the certification status of the architects, functional leads, technical leads, integration specialists, and other key consultants named for your engagement. SAP Certification is time-limited, so request the current status and validity date rather than relying on an undated certification claim. Certification should not replace delivery experience, but it provides another verifiable data point when evaluating the proposed team.

Ask to see: The named team, role-to-certification mapping, current certification status, and relevant project experience for key positions.

10. Which security, quality, continuity, and regulatory controls apply to this engagement?

Ask for more than ISO or compliance logos. For each relevant certification or standard, request the certifying body, validity period, and scope. Confirm that the scope actually covers the services, locations, or entities involved in your engagement.

If the implementation involves regulated processes or sensitive data, ask how responsibilities for security, data protection, access control, segregation of duties, audit evidence, business continuity, and regulatory requirements will be divided.

Ask to see: Current certificates, audit scope, security responsibilities, applicable policies, and evidence from comparable regulated engagements where appropriate.

Questions 11–14: Governance and Organizational Change

A large SAP program will encounter decisions that were not anticipated in the original statement of work. Governance determines how quickly those decisions are made, who can make them, and how their impact is reflected in the plan and budget.

11. What governance bodies and decision rights will control the program?

Ask for the governance structure before signature, not after kickoff. The partner should define who makes decisions at the program, architecture, and workstream levels; how frequently each group meets; what gets escalated; and who has final authority over scope, architecture, budget, quality, and go-live.

A typical structure may include:

The exact structure may differ, but decision rights should not remain implicit.

Dive into S/4HANA Steering Committee specifics

Learn how an SAP S/4HANA steering committee can structure decision-making, escalation, accountability, and governance throughout a transformation.

Read the article

12. How are scope changes assessed, approved, and re-baselined when something unplanned happens?

Acquisitions, new plants, regulatory changes, reorganizations, additional countries, new interfaces, or unexpected technical constraints can alter a multi-year program.

Ask what happens after a change is identified: who analyzes the impact, who approves it, how quickly an impact assessment must be produced, and when authority moves from the project team to the steering committee. Then connect governance to execution. Establish how schedule, resource, scope, and dependency impacts are assessed and how the project baseline is updated after approval.

Ask to see: The change-control procedure, approval thresholds, sample change request, impact-assessment approach, and re-baselining rules.

13. When does organizational change management start, and what does it produce?

Organizational change management should begin before training. Ask how the partner will identify affected stakeholders and roles, assess changes in processes and responsibilities, prepare communications, develop training, establish readiness criteria, and measure adoption after go-live.

The OCM workstream should also align with rollout sequencing. A technically ready module or country is not necessarily organizationally ready to deploy.

Ask to see: The stakeholder map, role-impact assessment, communications plan, training strategy, readiness criteria, and adoption measures.

14. What happens when a milestone or quality threshold is missed?

Every proposal contains an escalation path. The more useful question is how it works in practice. Ask for a recent example in which a milestone, quality gate, dependency, or acceptance criterion was missed. The partner should explain the trigger, who became involved, how the issue affected the baseline, what corrective actions were agreed upon, and when the program returned to plan. This gives you evidence of governance under pressure rather than governance on a slide.

Ask to see: The escalation process, issue and risk logs, recovery-plan template, and a redacted example from a comparable program.

Questions 15–20: Commercial Model, Team, Support, and Exit

A technically sound proposal can still create problems if commercial assumptions, delivery responsibilities, staffing commitments, and post-go-live obligations are unclear. These final questions test what you are actually buying and what happens as the engagement evolves.

15. How are responsibilities divided among SAP, your team, third parties, and ours?

Ask for explicit responsibility boundaries across implementation, infrastructure, technical operations, integrations, data migration, testing, security, upgrades, support, and application management.

This is particularly important when several providers participate in the landscape. For SAP Cloud ERP Private engagements, including RISE with SAP journeys, confirm the responsibilities assigned to SAP and the customer under the applicable service description and roles-and-responsibilities documents, as well as those assigned separately to the implementation and application-management partners. Where hyperscaler infrastructure is used, clarify whether any responsibilities sit directly with the customer.

The situation to prevent is an incident reaching production and each party claiming the other owns it.

Ask to see: The end-to-end responsibility matrix, support-routing model, applicable SAP roles-and-responsibilities documentation, and contractual responsibility boundaries.

16. Which named people will actually deliver our project, where are they based, and will subcontractors be used?

The team that sells an SAP implementation is not always the team that delivers it. Ask which architects and workstream leads are committed to the engagement, their planned allocation, location, start date, and relevant experience. Clarify which roles are filled by employees and which may be provided by subcontractors.

Then establish replacement rules. If a named person leaves the project, the contract should define notice and knowledge transfer requirements, as well as your approval rights for a replacement.

Ask to see: The named team structure, CVs or project profiles, allocation plan, delivery-location model, subcontractor disclosure, and replacement clause.

17. How will the team scale as we add countries, business units, or modules?

Large programs rarely maintain a constant team size. Ask how additional consultants are sourced, onboarded, and brought up to speed without repeatedly consuming the time of your most experienced project members. The partner should explain how architectural consistency, documentation, and institutional knowledge are maintained as the team changes.

Commercial details matter here as well. Establish whether onboarding, knowledge transfer, overlap between outgoing and incoming consultants, and travel are billable.

Ask to see: The resource ramp plan, onboarding approach, capacity assumptions, and pricing rules for adding resources.

18. What exactly is included in the quoted price, and which assumptions can change it?

A project price is meaningful only together with the assumptions behind it. Ask whether the commercial model is fixed price, time and materials, capped time and materials, or a hybrid, and how invoicing and payment milestones are structured. Then review the exclusions and dependencies that can generate additional cost.

Relevant items may include data cleansing, additional migration cycles, interfaces, test automation, nonproduction environments, third-party tools, travel, after-hours cutover work, localizations, documentation, training, hypercare, and additional scope discovered during Explore.

Also, ask how rates can change over a multi-year engagement and whether currency, inflation, location, or seniority changes can affect them.

Ask to see: The complete commercial assumptions, exclusions, rate card, payment milestones, change-pricing mechanism, and any limits on price increases.

19. What happens after go-live, from hypercare through steady-state support?

Treat hypercare and long-term support as one service transition rather than two unrelated discussions. Ask how long hypercare lasts, which project resources remain available, what coverage hours apply, how incidents are prioritized, and which exit criteria must be met before the project moves into normal support. Then, examine the steady-state model. Ask for service levels by severity, support hours and time zones, escalation targets, included capacity, out-of-scope work, and the treatment of enhancements versus incidents.

For global operations, confirm what receives follow-the-sun coverage and what waits until the next business day.

Ask to see: The hypercare plan, exit criteria, SLA table, support coverage model, escalation matrix, and pricing after hypercare.

20. If we part ways, what do we own, what must be handed over, and how does the transition work?

Exit terms are easiest to negotiate before the relationship begins. The contract should establish ownership and access rights for configuration documentation, architecture decisions, custom code, extensions, integration assets, migration programs, test assets, runbooks, training materials, and other project deliverables.

Ask how documentation must be maintained during the engagement rather than assembled only at the end. Then define the transition period, knowledge transfer obligations, required formats, access handover, and support for another provider or your internal team. A well-defined exit model reduces dependency on the implementation partner without assuming that the relationship will fail.

Ask to see: The IP and deliverable-ownership clauses, documentation requirements, knowledge-transfer plan, exit-assistance obligations, and transition timeline.

How To Use the 20 Questions

Do not judge partners on presentation quality alone. Evaluate each answer on two separate dimensions: how well the answer is supported by evidence and whether the proposed approach fits your requirements without creating unacceptable risk.

For evidence quality, a simple three-level model works well:

Then assess the proposed answer itself separately:

Do not combine these dimensions into a single partner-suitability score. A proposal can earn an evidence score of 2 because it is thoroughly documented and still presents a material risk to your organization.

Look for patterns across the 20 questions instead. Weak evidence or unresolved risks related to data migration and integrations may indicate technical delivery concerns. Governance and change-control gaps can affect the schedule and budget. Unclear pricing assumptions can lead to unexpected costs, while staffing and exit provisions can create dependence on individual consultants or the partner itself.

Evidence does not need to expose confidential customer information. Redacted or anonymized project plans, architecture diagrams, RACIs, decision logs, migration reconciliation reports, cutover checklists, change requests, governance charters, and support SLAs can still provide meaningful validation.

Comparable references also need enough context to be useful. For example, an SAP S/4HANA migration reference is more meaningful when it identifies the scope, project duration, approximate delivery team size, customer participation, and go-live period rather than stating only that the implementation was successful.

The objective is not simply to identify which partner can produce the most evidence. It is to determine whether the partner's proposed delivery model is appropriate for your organization and whether the claims behind it can be independently verified.

FAQ

Before You Sign

By the end of the selection process, the most important delivery commitments, assumptions, responsibilities, and protections discussed during the evaluation should be reflected in the agreement.

Confirm that the statement of work and related contract documents capture the named team and replacement rules, scope and exclusions, customer responsibilities, deliverables and acceptance criteria, migration and testing responsibilities, governance and escalation, commercial assumptions, change-control process, cutover and hypercare obligations, service levels, IP ownership, documentation requirements, and exit assistance.

If an important promise exists only in the sales presentation or meeting notes, it is not yet part of the delivery model.

When you are ready to put these questions to a potential implementation partner, see why enterprises choose LeverX or explore our SAP consulting services.