Around the ERP, not against it: integrate, extend, migrate.
Clean-core extensions, integration layers and migration support for SAP and major ERP estates — engineering discipline applied to the system of record.
- Estate review
- Architecture
- Build
- Cutover & operate
Rule one: custom logic lives outside the core, connected by contract.
The ERP is where truth lives and agility goes to die — unless the architecture around it is deliberate. Years of well-intentioned customisation inside the core is why an upgrade becomes a programme, why a simple approval screen takes months, and why every new consuming system arrives as another point-to-point interface that nobody owns. The system of record is doing its job; the estate around it is doing several jobs badly.
We build clean-core extensions and integration layers that let product teams move quickly without corrupting the system of record, and we support migrations with the rehearsal discipline they deserve. Custom logic runs side by side on a modern stack or SAP BTP, calling into the ERP through governed contracts. Interfaces are inventoried, stabilised and re-fronted as APIs and events, usually over Kafka, so a new consumer subscribes rather than builds. Reporting reads from the warehouse rather than the transactional core — that half of the work sits with Data Engineering.
That is what keeps upgrades from becoming rewrites — and it is a decision about where code goes, not about which vendor you buy from. The principle holds on S/4HANA, on Oracle, on Dynamics and on the long tail.
Four pieces of work, one architecture.
Most ERP estates need all four in some proportion. The review in phase one tells you which is urgent and which can wait.
Clean-core extensions
Side-by-side applications on SAP BTP or a modern stack of your choosing — the ERP stays standard, the differentiation lives outside it. Extensions read and write through released interfaces only, so a support pack or an upgrade is a regression test rather than a remediation project. In practice this is where the pleasant user interfaces go: approval apps, self-service portals, field and shop-floor screens that no core transaction should be asked to render.
Integration layer
IDoc, BAPI, RFC and OData fronted by governed APIs and events, so there is one contract per business object instead of one per consuming team. New consumers subscribe to a documented event or call a versioned endpoint; they never get database access or a bespoke file drop. The layer carries its own monitoring, retries and dead-letter handling, which is what makes interface failures visible early rather than at month-end.
Migration engineering
ECC to S/4HANA moves and consolidation programmes need engineering, not only configuration: data validation tooling, custom-code triage, interface re-pointing, parallel runs and rehearsed cutovers. We build the harness that compares the new system’s output against the old one on the same inputs, and we rehearse the cutover until the runbook runs cleanly. Every rehearsal produces a defect list and a timing, which is what turns a go-live decision into a fact.
Process automation
Workflows that span the ERP and the rest of the estate — approvals, procurement, finance operations, vendor onboarding — without a person re-keying between systems. Rules, thresholds and delegation live in the workflow layer where the business can change them, while the ERP keeps the postings and the master data. Where the process is a standard back-office one, Workflow & Procurement already implements it and connects to the ERP through the same contracts.
How the work runs, day to day.
The boundary is the deliverable.
The first thing we produce is not code. It is a written boundary: which behaviour stays standard in the core, which moves outside it, and the contract between the two. Every existing customisation is classified — keep as standard, move out, retire because the process changed years ago — and the classification is signed off by the people who own the process, not only by IT. Once that boundary exists, two things follow. Upgrades stop being negotiations, because the core is close to standard. And product teams get a place to build that does not require a basis conversation, because the extension layer has its own release train and its own tests.
- Every customisation classified: keep, move out, or retire — with the owner named
- Released interfaces only; no direct table access from anything outside the core
- Extensions on their own release train, with contract tests against the ERP
Interface chaos is an inventory problem first.
Estates rarely know how many interfaces they have, and the number on record is rarely the number running. Unowned, undocumented and duplicated flows are the norm — several teams pulling the same vendor master different ways. So the work starts with an inventory: every flow, its direction, its owner, its volume, its failure rate and what happens downstream when it stops. The flaky ones get stabilised where they are. Then the ones with several consumers are re-fronted as governed APIs and events, and the point-to-point links behind them are retired rather than left running quietly.
- Inventory with owner, volume, failure rate and business impact per flow
- Stabilise first, re-front second — no new architecture on top of failing plumbing
- Per-flow dashboards and alerting, so a stopped interface is noticed before finance is
A cutover you have already rehearsed.
Migration risk is concentrated in the hours nobody has practised. Our part of an ECC to S/4HANA programme is the engineering spine: tooling that validates data before and after the move, a harness that runs the same inputs through both systems and reconciles the results line by line, custom-code triage against the new release, and interface re-pointing with contract tests. Then the cutover is rehearsed end to end — with real volumes and the real runbook — until timings are known and the defect list is empty. The go-live weekend is not the first time the team has done it.
- Parallel-run reconciliation, line by line, with the differences explained rather than tolerated
- Custom-code triage: what must be rewritten, what moves out of the core, what is deleted
- Timed cutover rehearsals with a rollback point, plus hypercare monitoring on every interface
What each side of the table gets.
A core that stays close to standard.
The custom code inside the core shrinks, the remaining objects are documented and tested, and everything new arrives through released interfaces. Upgrades become a scheduled regression run instead of a discovery exercise, and the basis team stops being the bottleneck for every product idea in the company.
- Custom-code inventory with a retirement plan and an owner per object
- Contract tests that run before every support pack and upgrade
- Extensions deployed on their own pipeline, not through the core transport chain
A place to build that does not need a basis conversation.
Side-by-side applications get their own repositories, environments and release cadence, with the ERP reachable through a documented contract. Teams ship on their own cadence against a production-shaped sandbox instead of queuing for a transport window, and a new consumer of vendor or order data subscribes to an event rather than commissioning an interface.
- Versioned APIs and events per business object, documented and discoverable
- Production-shaped sandbox with masked data for every extension team
- Delivery patterns shared with Integration & API Development
Postings that reconcile, and interfaces that report themselves.
Finance cares about two questions: does the number match, and will anyone notice if a feed stops. Contract tests and parallel-run reconciliation answer the first during a migration; per-flow monitoring answers the second on an ongoing basis afterwards. Approval rules and delegation move to a layer the business can change, with the audit record kept on every decision.
- Parallel-run reconciliation reports as the evidence for a go-live decision
- Per-interface availability monitoring with an owner and an escalation path
- Approval thresholds and delegation as configuration, with a full audit trail
What we connect the ERP to, and how.
SAP S/4HANA · ECC
Vendor master, purchase orders, goods receipt, invoice postings and cost objects through IDoc, BAPI/RFC and OData — fronted by versioned APIs and events.
SAP BTP
Side-by-side extensions, event mesh and destination services, deployed from your own pipelines with the same tests as the rest of the estate.
Oracle · Dynamics · other ERPs
The clean-core principle is vendor-neutral: released interfaces, an integration layer, and no business logic in the reporting database.
Warehouse management & shop floor
Stock movements, confirmations and MES signals, buffered so a network outage becomes a backlog rather than a lost posting.
CRM and commerce
Customer and pricing master flowing out, orders flowing in, with idempotent handling so a retried order never posts twice.
Banking and e-invoicing
Payment files, bank statements and statutory e-invoicing endpoints, with reconciliation and retention handled as a first-class requirement.
Data warehouse & BI
Change data capture into the warehouse so reporting stops querying the transactional core — see Power BI and Data Engineering.
Workflow & procurement
Approvals, vendor onboarding and procurement processes running outside the core, on Workflow & Procurement or your own workflow layer.
Four phases, each with something you can use.
Estate review
Modules, customisations, integration points — and the upgrade debt hiding in each. Every custom object and every interface is inventoried with an owner, a volume and a failure rate, and the review ends with a classification: keep standard, move out, retire. Its output stands on its own whether or not you continue.
Architecture
The clean-core boundary: what stays standard, what moves out, and the contracts between. We define the API and event catalogue per business object, the extension runtime, the environments and the test strategy, then agree the order of work with the process owners rather than only with IT.
Build
Extensions and integration flows delivered sprint by sprint, tested against a production-shaped sandbox with masked data. Each flow ships with its monitoring, its retries and its dead-letter handling, and each extension ships with contract tests against the ERP release you are on.
Cutover & operate
Rehearsed go-lives with timed runbooks and a rollback point, hypercare with monitoring on every interface, then business as usual — calmer than before. Where you want us to keep running the estate, that continues under DevOps & Cloud with agreed service levels.
What is handed over, and to whom.
- Integration architecture with governed API/event contracts
- Clean-core extension applications
- Migration validation tooling and parallel-run evidence
- Interface monitoring with per-flow dashboards
- Documentation your basis and product teams both accept
When this is the right call.
Choose this when the ERP is the system of record and the constraint at the same time: upgrades take quarters, every new consumer becomes another interface, and product ideas die waiting for a transport window. It fits organisations preparing an ECC to S/4HANA move who need an engineering spine alongside their SI, groups consolidating several ERPs after an acquisition, and estates where interface failures are discovered by finance rather than by monitoring. It also fits the quieter case: the ERP is fine, but the processes around it are still run on spreadsheets and email.
It is the wrong engagement if what you need is core module configuration or a full implementation partner — that is your SI’s work, and we would rather keep the architecture honest beside them than pretend otherwise. It is wrong when the organisation is unwilling to move logic out of the core, because the whole method rests on that boundary. And it is premature when the process itself is undecided: agree what approval or procurement should look like first, then automate it.
Frequently asked questions
Where this service usually sits.
Tell us what you’re building.
Describe what exists today and what you need. An engineer reads it and replies in writing with how we would approach it, and the model that fits.