SAP Integration
The technical work is the easy part. The licence and change control are not.
What is SAP?
SAP integration means connecting other systems to an SAP environment, where the constraints are as much contractual and procedural as technical, since licensing, support agreements and change control all limit what may be done and by whom.
SAP integrations are unusual in that the technical approach is frequently decided by commercial terms rather than by engineering. What your licence permits, what your support agreement covers and who your implementation partner is can all rule out an otherwise sensible design.
Indirect access is the question that catches organisations hardest. Where an external system reads or writes SAP data, licensing implications can follow, and they are considerably easier to establish before building than after an audit.
Change control is the other one. In most SAP environments a change moves through defined transport and approval steps for good reasons, and an integration project that assumed otherwise arrives at a queue nobody warned it about.
What we ask in the first conversation
Duara integrates with SAP from Nairobi, working alongside your existing SAP partner rather than around them.
We ask about your licence and support agreement in the first conversation. It is not what anybody expects a technical supplier to open with, and it prevents the design that turns out to be commercially unavailable after the work has started.
Who this is for
- Data is rekeyed between SAP and other systems
- You need SAP data in a system that cannot reach it
- A previous integration raised licensing questions
- Change control makes projects slower than expected
Industries we serve
- Manufacturing
- Large distribution
- Energy and utilities
- Financial services
- Public sector
- Multinational operations
Problems this solves
These are the practical realities of integrating with an enterprise system somebody else supports.
- Licensing implications discovered late. External systems reading SAP data can carry licensing consequences, and finding out after an audit is expensive.
- Change control not accounted for. Transport and approval steps exist for good reasons and add time that project plans routinely omit.
- Support agreement constraints. What may be modified and by whom is governed by an agreement, and breaching it can affect your support position.
- Rekeying between SAP and everything else. Data exists in SAP and gets retyped into the systems people actually work in daily.
What we deliver
Establishing the commercial constraints first, working within change control rather than around it, using supported interfaces, and coordinating with your existing SAP partner.
Licensing and support position established first
Integration through supported interfaces only
Work planned around your change control process
Coordination with your existing SAP partner
Documentation suitable for your support arrangements
A view on whether the integration is commercially sensible
Features
- Commercial questions asked first. Licence and support terms are established before design, since they can rule out an otherwise sensible approach.
- Indirect access raised early. Where external systems touch SAP data, licensing implications are far cheaper to establish before building than after an audit.
- Supported interfaces only. We do not modify core objects or use unsupported routes, since either can affect your support position.
- Change control respected. Transport and approval steps are planned into the timeline rather than discovered as a queue.
- Your SAP partner involved. We work alongside them rather than around them, because they carry the support relationship and we do not.
Benefits
- No commercial surprises. Licensing questions settled before build rather than during an audit conversation.
- Support position preserved. Using supported interfaces means your existing arrangements remain intact.
- Realistic timelines. Change control planned in rather than discovered means the estimate reflects the actual process.
- Rekeying removed. Data in SAP reaches the systems people work in without somebody retyping it.
Technologies we use
- Supported interface integration. Connecting through published and supported routes rather than direct database access.
- Licensing assessment. Establishing the indirect access position before any design is committed to.
- Change control alignment. Planning work through your transport and approval process rather than alongside it.
- Partner coordination. Working with your existing SAP implementation partner rather than in parallel.
- Middleware where appropriate. Using integration layers where they reduce direct coupling and licensing exposure.
The technical options are usually well understood and the commercial constraints decide between them. That inversion is what makes SAP integration different from almost any other platform in this list.
How the process works, step by step
SAP integration timelines depend more on your change control process than on development, and we estimate against your process rather than a generic one.
-
Step 1
Free constraints review
We establish your licence position, support agreement and change control process before discussing technical options.
-
Step 2
Licensing question settled
Indirect access implications are confirmed, since this is where the expensive surprises live.
-
Step 3
Partner engaged
Your existing SAP partner is brought in early, because they hold the support relationship.
-
Step 4
Built on supported routes
Integration uses published interfaces so your support position stays intact.
-
Step 5
Moved through change control
Deployment follows your process, with the timeline reflecting it rather than ignoring it.
Quality assurance and how we work
The commitments attached to touching an enterprise system somebody else supports.
- We ask about licensing first. It is not what anybody expects a technical supplier to open with, and it prevents a design that turns out to be commercially unavailable.
- We use supported interfaces only. Modifying core objects or using unsupported routes can affect your support position, which is not our risk to take on your behalf.
- We work with your SAP partner. They carry the support relationship and we do not, so working around them would be leaving you exposed.
- We plan around change control. Transport and approval steps exist for good reasons, and pretending they do not adds a queue to your project rather than to ours.
- We will say when the integration is not worth it. Where licensing or change overhead outweighs the benefit, that is worth knowing before rather than after.
Frequently asked questions about SAP
What makes SAP integration different?
Commercial constraints decide the technical approach. Licence terms, support agreements and change control can rule out an otherwise sensible design.
What is indirect access?
External systems reading or writing SAP data, which can carry licensing implications. Far cheaper to establish before building than after an audit.
Why ask about licensing first?
Because it can make a design commercially unavailable. It is not what people expect a technical supplier to open with and it prevents an expensive discovery.
Will you modify our SAP core?
No. We use supported interfaces only, since unsupported routes can affect your support position and that is not our risk to take.
Do you work with our SAP partner?
Yes, and we bring them in early. They carry the support relationship and working around them would leave you exposed.
How does change control affect timelines?
Considerably, and we estimate against your actual process rather than a generic one. Transport and approval steps are not optional.
Can you read SAP data into another system?
Yes, through supported interfaces, with the licensing position confirmed first because that is where the surprises live.
Can you write into SAP?
Yes, where your licence and change control permit it, and both are established before design rather than during it.
Do we need middleware?
Sometimes, and it can reduce coupling and licensing exposure. We would say when it is genuinely justified rather than adding a layer by default.
What about older SAP versions?
They are common and workable. Available interfaces differ and we establish what exists rather than assuming a modern platform.
How long will it take?
It depends more on your change control process than on development, which is why we estimate against your process rather than a standard figure.
Will you tell us not to integrate?
Yes, where licensing or change overhead outweighs the benefit. That is worth knowing before the work rather than after.
Can it connect SAP to a CRM?
Yes, and it is a common request, with field ownership decided so the two systems do not overwrite each other.
Does it work with SAP Business One?
Yes, and it is a different platform from the larger SAP products with its own interfaces, which we would scope separately.
Who is responsible if something breaks?
Support boundaries are agreed upfront between us, you and your SAP partner, rather than established during an incident.
Can our IT team maintain it?
Yes, on the integration side, documented accordingly. Anything inside SAP stays with whoever supports your SAP.
Does SAP data get copied outside our estate?
No. Integration runs inside your own infrastructure and SAP records stay where they are.
Can it handle high transaction volumes?
Yes, with batching designed for it, and volume is one of the things we size against your real figures rather than estimates.
Who can access SAP through the integration?
A dedicated integration account with the narrowest permissions that work, which you control and can revoke.
What does an SAP integration cost?
Interface availability and change control overhead determine it, quoted after the constraints review.
Glossary of terms
SAP terms in plain language.
- Indirect access
- External systems reading or writing SAP data, which can carry licensing implications.
- Transport
- The controlled mechanism for moving changes between SAP environments.
- Change control
- The approval process governing what may be changed and when.
- Supported interface
- A published route SAP supports, as distinct from direct database access.
- Middleware
- An integration layer between SAP and other systems, reducing direct coupling.
- Implementation partner
- The firm holding your SAP support relationship, who should be involved rather than bypassed.
Related services in Integrations
Talk to us about SAP
Ask your SAP partner what your licence says about indirect access. That answer shapes everything else.
Start your project