Choosing the right SAP BTP consulting partner is not simply about finding developers who know the platform. It means finding a partner who understands your business processes, evaluates the available architectural options, manages integration complexity and helps you build a solution that remains maintainable after go-live.
An SAP S/4HANA transformation is progressing as planned. Then a question emerges during a steering committee meeting: Where should the custom applications, interfaces, reports and carrier integrations run after the migration?
The ERP implementation partner has delivered the core system, but the architecture for extensions and integrations remains unclear. Some customisations may still depend on the existing SAP environment. Others need to connect warehouses, transport management systems, suppliers and third-party applications.
This is where SAP Business Technology Platform (SAP BTP) becomes an important architectural consideration.
For organisations planning an SAP S/4HANA transformation, modernising legacy middleware or improving supply chain processes, the right partner can help turn technology decisions into a practical implementation roadmap.
This guide explains what SAP BTP consulting services should cover, how to evaluate implementation partners, which questions to ask before signing a contract and what to look for in a credible proposal.
The short answer: What makes a good SAP BTP implementation partner?
A good SAP BTP implementation partner connects technical decisions to measurable business requirements.
Before selecting a provider, evaluate five areas:
- Architecture and clean core: Can the partner explain when to use standard SAP functionality, in-app extensibility or side-by-side extensions on SAP BTP?
- Production integration experience: Has the team delivered and supported integrations in environments comparable to yours?
- Business and industry knowledge: Does the partner understand the operational processes behind your requirements?
- Commercial transparency: Can the partner explain implementation costs, consumption assumptions, licensing considerations and ongoing support?
- Long-term ownership: Will your organisation receive the documentation, code, operational knowledge and support arrangements needed to manage the solution?
Request evidence for each area. Production references, architecture assessments, documented implementation plans and transparent cost assumptions are more useful than general claims about expertise.
What do SAP BTP consulting services include?
SAP Business Technology Platform provides capabilities for application development, integration, automation, data and analytics, and other business technology scenarios.
SAP BTP consulting services help organisations decide which capabilities they need, design the architecture, implement the required solutions and operate them effectively.
The scope varies by organisation, but the following areas are common considerations.
Consulting area | Typical activities | Business objective |
SAP integration | API management, system connectivity, event-driven integration and interface modernisation | Connect SAP and non-SAP systems reliably |
Application development | Custom applications, extensions and digital workflows | Address requirements not covered adequately by standard functionality |
Clean-core architecture | Extension assessment, API strategy and development governance | Reduce unnecessary modifications to the SAP core |
Process automation | Workflow automation, approvals and exception handling | Reduce manual effort and improve process consistency |
Data and analytics | Data integration, reporting and analytical applications | Improve visibility and decision-making |
Platform governance | Account structure, identity, security, monitoring and cost controls | Establish a manageable and controlled platform |
Application support | Monitoring, incident resolution, maintenance and optimisation | Maintain operational reliability after deployment |
The important distinction is that consulting should not automatically result in more custom development.
An efficient partner first determines whether the business requirement can be met through standard SAP functionality, configuration or an existing integration. Only then should it recommend a custom extension or additional platform service.
Why SAP BTP matters in an SAP S/4HANA transformation
SAP BTP can support an organisation’s transition towards a more modular and manageable SAP landscape.
For example, an organisation may need to introduce a carrier-facing application, connect a warehouse system to additional platforms or automate a workflow that crosses several enterprise applications.
Building every requirement directly into the ERP core can create dependencies that make future upgrades and changes more difficult. However, moving every requirement to SAP BTP is not automatically the right answer either.
The objective is to choose the appropriate extension approach for each business requirement.
Understanding clean core
The clean-core approach encourages organisations to preserve the integrity and upgradeability of their SAP core while supporting necessary business differentiation.
SAP’s extension architecture guidance describes both on-stack extensibility and side-by-side extensibility on SAP BTP. The appropriate choice depends on the business use case, technical requirements and available capabilities.
Three common approaches are worth understanding.
Extension approach | When it may be appropriate | What to evaluate |
Key-user extensibility | Simple adaptations, fields and supported configuration-based extensions | Whether standard tools satisfy the requirement |
Developer extensibility using ABAP Cloud | More complex extensions that need close interaction with SAP application data and processes | Released APIs, development constraints and lifecycle requirements |
Side-by-side extensibility on SAP BTP | New applications, cross-system processes and extensions with an independent lifecycle | Integration design, security, operations and consumption costs |
The decision should be based on the actual requirement rather than a blanket preference for one technology.
For instance, adding a supported custom field to an SAP application may not justify building a separate BTP application. By contrast, a workflow that coordinates information across SAP S/4HANA, a warehouse management system and external logistics providers may benefit from a decoupled architecture.
SAP’s Extension Architecture Guide provides further guidance on selecting an appropriate approach.
How should a partner assess clean core?
Before development starts, ask the partner to establish a baseline of your current landscape.
A useful assessment should identify:
- Existing custom developments and their business purpose.
- Dependencies on SAP standard objects and interfaces.
- Available released APIs and supported extension options.
- Potential upgrade and maintenance risks.
- Extensions that could be retired, replaced or redesigned.
- Priorities, remediation effort and recommended next steps.
The output should be a prioritised assessment, not simply a statement that the organisation should adopt clean core.
SAP also provides a clean-core measurement framework to help organisations monitor compliance and progress over time. See the SAP clean-core guidance.
Seven things to evaluate when choosing an SAP BTP consulting partner
1. The partner can explain when not to use SAP BTP
One of the strongest signs of sound architecture is the ability to reject unnecessary complexity.
A requirement might be achievable through standard SAP functionality, configuration or supported in-app extensibility. Another may justify a side-by-side application because it needs an independent lifecycle or integration across several systems.
Ask the partner to explain a recent architectural decision, including the alternatives considered and why the selected approach was appropriate.
A credible answer should cover business value, implementation effort, integration dependencies, security and long-term maintenance.
2. The partner has relevant production experience
A proof of concept can demonstrate technical feasibility, but it does not establish that a solution is ready for enterprise operations.
Ask for examples of comparable production implementations and establish what the partner actually delivered.
Useful questions include:
- Which systems were integrated?
- What business processes were supported?
- How were failures, retries, and exceptions handled?
- What monitoring and alerting were implemented?
- How were performance and security requirements tested?
- Who supports the solution today?
Where confidentiality prevents the disclosure of customer names, ask for an anonymised architecture, a description of the implementation scope, and a reference that can be contacted with permission.
3. Integration is a core capability
Integration is often one of the most important parts of an SAP BTP programme.
A sound integration approach should consider API availability, authentication, data consistency, message handling, monitoring, retry behaviour, performance and error recovery.
For organisations using SAP Process Orchestration (PI/PO), the partner should also be able to assess the existing interface landscape and develop a migration strategy for suitable scenarios to SAP Integration Suite.
A migration assessment should cover:
- Interface and adapter inventory.
- Custom mappings and dependencies.
- Compatibility and redesign requirements.
- Security, certificates and connectivity.
- Testing, reconciliation and parallel-running requirements.
- Cutover sequencing and rollback planning.
- Post-migration monitoring and support.
SAP provides product-specific guidance through the SAP Help Portal.
Do not assume every interface can be migrated through a simple one-to-one conversion. Some may need redesign, consolidation or a different integration pattern.
4. The partner understands your industry and processes
Technical expertise becomes more valuable when it is combined with process knowledge.
In manufacturing, retail and logistics, SAP BTP use cases may involve shipment visibility, warehouse workflows, carrier connectivity, document handling, operational dashboards and exception management.
A partner that understands SAP EWM and SAP TM alongside integration architecture can evaluate requirements in the context of actual warehouse and transportation processes.
For example, a shipment-visibility requirement may involve more than connecting a tracking API. The solution may also need to reconcile shipment identifiers, process status updates, manage missing events and present exceptions to the right operational teams.
Ask the partner to demonstrate how it would approach a real business scenario in your industry.
The objective is to understand whether the team can translate operational problems into maintainable technical solutions.
SAP BTP project costs depend on the implementation scope, architecture, development effort, integration complexity, service consumption and ongoing operating model.
A proposal should distinguish consulting and implementation fees from SAP platform or service charges.
It should also explain the assumptions used to estimate effort and consumption.
Understand the main commercial models
SAP offers different commercial arrangements for BTP services. Depending on the customer’s contract and eligible services, these can include consumption-based models such as Cloud Platform Enterprise Agreement (CPEA), BTPEA and Pay-As-You-Go, as well as subscription-based arrangements.
The available options and terms must be confirmed for the customer’s actual account and service requirements.
Commercial approach | What to evaluate | Key question |
Consumption-based agreement | Eligible services, committed credits, consumption rules and contractual terms | How does projected usage compare with the commitment? |
Pay-As-You-Go | Applicable rates, service eligibility, billing and consumption controls | What will the expected cost be under realistic usage scenarios? |
Subscription-based arrangement | Included service, quantity, scope and contractual conditions | What happens when requirements exceed the agreed scope? |
These models are not interchangeable, and their precise terms vary.
Before making a decision, ask the partner to prepare a cost estimate based on your expected workloads and proposed architecture.
A useful estimate should include:
- Discovery and architecture assessment.
- Development and integration.
- Testing, deployment and security.
- Expected platform consumption.
- Monitoring and operational support.
- Maintenance and future enhancements.
Model at least three scenarios: a limited pilot, an initial production rollout and a scaled operating environment.
The partner should document the assumptions behind each scenario, identify exclusions and explain how actual consumption will be monitored after go-live.
Avoid choosing a commercial model solely because its initial commitment appears lower. The right choice depends on the workload, contract and expected pattern of use.
6. Security, governance and European requirements are addressed early
Security and governance should be part of the architecture from the beginning, not tasks left until deployment.
For organisations operating in Germany and other European markets, the evaluation should include data protection, access control, identity management, auditability, regional requirements and applicable regulatory obligations.
For AI-related use cases, the organisation should also assess data quality, permitted use, human oversight and the legal classification of the proposed system.
The EU AI Act contains different obligations and application dates depending on the system and its classification. Requirements should therefore be assessed against the specific use case and current legal guidance, rather than assuming that every AI application follows the same timetable.
Ask the partner to explain:
- How identities, roles and permissions will be managed.
- How sensitive information will be protected.
- Which logs and audit trails will be available.
- How integration credentials and certificates will be maintained.
- How the architecture will be monitored.
- Which compliance responsibilities belong to the customer, partner and relevant service provider.
Legal and regulatory interpretations should be confirmed with qualified advisers where necessary.
7. The partner has a credible handover and support model
Legal and regulatory interpretations should be confirmed with qualified advisers where necessary.
The implementation does not end when the application goes live.
BTP services, integrations and custom applications require monitoring, maintenance, access management, incident handling and periodic reviews.
Before signing a contract, clarify who will own and operate the solution after deployment.
Your agreement should address source-code ownership and access, documentation, architecture records, runbooks, monitoring, support responsibilities, service levels and knowledge transfer.
Ask how the partner will help your team become capable of managing the solution independently where that is the intended operating model.
A well-designed implementation should not create unnecessary dependency on the original delivery team.
A practical SAP BTP partner evaluation scorecard
A structured evaluation helps procurement and IT teams compare proposals using consistent criteria.
The following is an illustrative scoring model, not an industry benchmark.
Evaluation criterion | Suggested weight |
Relevant production delivery experience | 25% |
Integration and migration capability | 20% |
Architecture and clean-core approach | 20% |
Commercial transparency | 15% |
Security and governance | 10% |
Handover and ongoing support | 10% |
Total | 100% |
Calculate the weighted score by multiplying each criterion’s score by its weight and adding the results. If using percentages as weights, divide the total by 100 to obtain a final score out of 5.
For example, a partner with a strong presentation but limited production evidence should not receive the same score as a partner that can demonstrate comparable implementations, operational lessons and a credible support model.
Treat mandatory security, compliance and contractual requirements as pass/fail conditions where appropriate. A high overall score should not compensate for failure to meet a critical requirement.
Red flags to watch for when evaluating SAP BTP consultants
Several warning signs deserve closer scrutiny.
Every problem becomes a BTP project. A partner should be willing to recommend standard SAP functionality, configuration or a simpler alternative when appropriate.
Clean core is discussed without an assessment. Ask for evidence of how extensions, dependencies and remediation priorities will be evaluated.
The integration proposal focuses only on connectivity. Enterprise integration also requires monitoring, security, error handling, testing and operational ownership.
All references are demonstrations or proofs of concept. Ask what is running in production and how it is supported.
Pricing assumptions are unclear. Request a documented scope, estimated consumption, exclusions and scenario-based cost analysis.
AI is proposed without addressing data and governance. Ask how the solution will handle data quality, access controls, evaluation, oversight and applicable regulatory requirements.
Post-go-live responsibilities are undefined. Clarify who maintains the solution, responds to incidents and owns the operational documentation.
These questions help distinguish a technically plausible proposal from one that is ready for enterprise delivery.
Ten questions to ask an SAP BTP implementation partner
Use these questions during initial consultations or an RFP process.
- When would you choose standard SAP functionality or in-app extensibility instead of SAP BTP?
- How will you assess our current extensions, dependencies and clean-core readiness?
- Which SAP Integration Suite scenarios have you delivered and supported in production?
- How will you manage integration failures, retries, monitoring and performance?
- If we use PI/PO, how will you assess and sequence the migration?
- Who will deliver the work, and what experience do those team members have with comparable projects?
- How will you estimate implementation effort and BTP service consumption?
- How will you address security, identity management, data protection and applicable compliance requirements?
- What documentation, code access, runbooks and knowledge transfer will we receive?
- What would you advise us not to implement, and why?
Ask candidates to support their answers with concrete examples, assumptions and deliverables. The quality of the reasoning matters as much as the answer itself.
How to start an SAP BTP consulting engagement
A staged approach can help organizations understand the requirements before committing to a larger programme.
Step 1: Assess the current landscape
Document the existing SAP systems, interfaces, custom developments, business dependencies and operational constraints.
Identify which requirements are already supported by standard functionality and which may require extensions or new integrations.
Expected output: An agreed scope, current-state assessment and prioritised list of opportunities.
Step 2: Define the target architecture
Evaluate the appropriate extension and integration approaches for each priority use case.
Document dependencies, security considerations, interface requirements, governance needs and the expected operating model.
Expected output: A target architecture, decision rationale, risk register and implementation roadmap.
Step 3: Select a focused use case
Choose a use case with a clearly defined business problem, measurable success criteria and manageable dependencies.
For example, a supply-chain organisation might evaluate an integration or workflow that addresses a documented operational bottleneck.
Define the baseline, target outcome, scope and acceptance criteria before development begins.
Expected output: An approved use-case definition and a realistic delivery plan.
Step 4: Validate the solution and cost assumptions
Build or configure the agreed solution, test its technical and business behaviour, and compare actual consumption with the initial assumptions.
Include error scenarios, security, monitoring and operational handover in the validation process.
Expected output: A tested solution, documented results and a recommendation on whether to scale.
Step 5: Establish governance and ongoing support
Before expanding the programme, define ownership, development standards, access controls, monitoring, consumption reviews and support responsibilities.
This provides a foundation for adding further use cases without allowing the BTP landscape to become difficult to manage.
How NAV IT Consulting can support SAP BTP initiatives
NAV IT Consulting GmbH specialises in SAP-led digital supply chain and procurement transformation.
Its service portfolio spans SAP BTP, SAP S/4HANA, SAP Extended Warehouse Management (EWM), SAP Transportation Management (TM), SAP Ariba, SAP Business Network for Logistics and related automation capabilities.
This focus is relevant to organisations where BTP requirements are closely connected to logistics, warehouse operations, transportation processes and enterprise integration.
Depending on the requirements, a consulting engagement may involve architecture assessment, integration planning, extension design, workflow automation or support for a broader digital supply chain transformation.
The appropriate scope should be determined by the organisation’s existing landscape and business objectives rather than by a predefined technology package.
Explore NAV IT’s SAP BTP consulting services to understand the available capabilities and discuss how they may align with your requirements.
For organisations with broader transportation and warehouse transformation objectives, NAV IT also provides SAP supply-chain consulting services.
The key consideration is whether the proposed team, delivery experience and engagement model match the specific project. Request a discussion about your use case, expected outcomes and implementation constraints before deciding on the scope.
Frequently asked questions about SAP BTP consulting services
1. What does an SAP BTP consultant do?
An SAP BTP consultant helps organisations assess, design, implement and support solutions involving integration, application development, extensions, automation, data and other platform capabilities. The work may include architecture decisions, security, governance, cost estimation and operational planning.
2. How do I choose an SAP BTP implementation partner?
Evaluate production experience, integration capability, clean-core knowledge, industry expertise, commercial transparency and long-term support. Request relevant references, an implementation plan and evidence to support the partner’s recommendations.
3. Do I need SAP BTP if my organisation still uses SAP ECC?
Not necessarily. The decision depends on the use case and current architecture. SAP BTP may support integrations or extensions in an existing SAP landscape, but the organisation should assess the available options, dependencies and future transformation plans before investing.
4. What is the difference between SAP BTP and SAP Integration Suite?
SAP BTP is the broader technology platform. SAP Integration Suite is an integration capability within that platform that supports connectivity and integration scenarios across systems and applications.
5. How much do SAP BTP consulting services cost?
There is no single price that applies to every project. Costs depend on scope, complexity, development and integration effort, testing, security, service consumption and ongoing support. Request an estimate based on documented assumptions and distinguish consulting fees from SAP platform charges.
6. How long does an SAP BTP implementation take?
The duration depends on the number of systems involved, the complexity of the use case, available APIs, security requirements, testing and organisational readiness. A focused integration may have a very different delivery timeline from a multi-system transformation. A discovery assessment should establish a realistic schedule.
7. Is SAP BTP required for clean core?
No. Clean-core architecture involves selecting appropriate approaches to configuration, in-app extensibility and side-by-side extensions. SAP BTP is an important option for decoupled extensions, but not every requirement needs a separate BTP application.
8. What should an SAP BTP implementation proposal include?
A credible proposal should include the business objectives, scope, architecture, assumptions, dependencies, security approach, implementation phases, testing strategy, cost estimate, acceptance criteria, support arrangements and handover deliverables.
Choose your SAP BTP consulting partner with confidence
The right SAP BTP implementation partner should help your organisation make better architectural decisions, not simply deliver more technology.
Look for a team that understands your business requirements, can demonstrate relevant delivery experience, explains commercial assumptions clearly and takes responsibility for maintainability beyond go-live.
Start with an assessment of your landscape and a small number of well-defined priorities. Establish measurable success criteria, validate the architecture and consumption assumptions, and expand only when the results justify it.
If you are evaluating SAP BTP for an SAP S/4HANA transformation, integration modernisation or digital supply chain initiative, speak with NAV IT Consulting about your requirements and the options worth evaluating.
