Lima Backbone moves data between the systems you run, changes its shape on the way, and brings results back. It handles the simple jobs, such as a nightly copy of ERP tables into your data lake, and the demanding ones, such as a full integration between SAP or Oracle and your planning applications with the results written back into the ERP. The tools and the way of working stay the same at every level.
Each level adds capability on top of the one before it. A team can start with a nightly copy and grow into a full planning integration without changing tools.
Take tables from an ERP, a database or a file location and land them somewhere useful, on a schedule or as changes happen. This is the everyday job of a data team, and it is where most Backbone estates start.
Move the complete history of a system into a lakehouse, tier cold data out of an expensive ERP database, or retire a legacy system while its data stays readable. Each table is reconciled: rows in, rows out, totals compared.
Combine data from several ERPs into one consistent model, keep master data aligned across systems, and feed reporting, partner and planning systems from the same governed copy. Change capture keeps the copies current.
Deliver data into Kinaxis, o9, Blue Yonder, SAP IBP or OMP before the planning run, apply transformations at MRP scale, route bad records to the people who own them, and write accepted plans back into SAP or Oracle with a confirmation for every write.
Every job on the Backbone follows the same six steps. Simple jobs use the first three or four; a planning integration uses all six.
| Step | What happens | What Backbone brings to it |
|---|---|---|
| 1 · Extract | Data is read from the source: the whole table, only the rows that changed since the last run, or every change as it happens. | Reads SAP and Oracle through the interfaces each vendor supports, with delta and change capture built in. ERP extraction → |
| 2 · Transform | Data is cleaned, joined, converted and calculated into the shape the target needs. | 150+ visual operators, Python where you need it, and a parallel engine for very large joins. Pipelines → |
| 3 · Load | Data is written to the target: inserted, updated in place, replaced, or loaded into a partition. | Target-aware writes for warehouses, lakehouses, databases, files and planning applications. |
| 4 · Orchestrate | Jobs run on a schedule, on an event, or in time for a business deadline, and are watched while they run. | Deadlines on the business calendar; jobs pause on a data problem and resume from where they stopped. Orchestration → |
| 5 · Check | Rows that fail a rule are separated from valid rows; counts and totals are compared with the source. | Every rejected row is kept and becomes a record with an owner and a deadline. Exceptions → |
| 6 · Return | Results such as accepted plans or corrected master data are written back into the source system. | Every write carries a unique key, is confirmed by the ERP, and is reconciled at the end of the run. Write-back → |
Three jobs, written out step by step. The same six steps apply; the difference is how many of them the job needs and how much rides on each one.
otif_nightly: SAP changes and WMS data pass a quality check, feed the OTIF calculation and a certified view, and fan out to the board KPI, the SC report and the OTIF API before the 06:30 deadline. When a data problem was detected at 02:14, the pipeline paused, resumed at 02:58, and finished with three and a half hours to spare.
Each item has its own capability page with its evidence. Together they turn a set of pipelines into a backbone the business can rely on.
SAP is read through tables, BAPIs, CDS views and application-level change capture. Oracle is read through database access, delta capture and released APIs. No add-on is installed in either system, and no extra vendor licence is needed.
Plans, requisitions and corrected master data go back into the ERP through its released transactions. Every write carries a unique key, receives a confirmation from the ERP, and is reconciled at the end of the run.
A job is scheduled against the business event it serves, such as the 06:00 MRP run or the Friday S&OP review. When a data problem stops a job, it pauses, keeps its place, tells the owner, and resumes once the data is fixed.
Incoming data is split into valid rows and exception rows. Each exception keeps its full context, goes to the buyer, planner or steward responsible, and is replayed into the pipeline once it is fixed.
One parallel engine handles a nightly delta and a terabyte migration. Subscription is sized by the capacity you run on, so a large migration costs the same as a small one.
Every run keeps checkpoints. After a hold, a network fault or a source outage, the job resumes from its last checkpoint and replays the changes it missed in order, without duplicates.
Pipelines use the same catalog, lineage, quality rules and access policy as everything else on Lima. Lineage is recorded as the pipeline runs, and access rules apply to the data it moves.
The platform gives you two ways to work with data. The Data Fabric reads data where it lives, for questions, dashboards and agents. The Backbone moves data when a system needs a prepared, checked copy delivered on time. Both use the same catalog, lineage, quality rules and access policy, so the choice depends only on the job.
| What you want to do | Read it in place (Data Fabric) | Move it (Backbone) | Why |
|---|---|---|---|
| Ask questions, build dashboards, run agents | Yes | — | The data is read where it lives and answers come back in seconds. The data stays in the source system. |
| Feed a planning application | — | Yes | Planning engines load a prepared dataset inside a time window; they need the data delivered, checked and on time. |
| Calculate at MRP scale | — | Yes | Exploding a 20-level bill of material for millions of item-plant combinations is heavy computation, which is what the parallel engine is for. |
| Keep a month-end or regulatory snapshot | — | Yes | An auditor needs a fixed copy with a hash, kept as evidence. |
| Archive, offload or retire a system | Read the archive | Move it once | The Backbone moves the history; the Fabric keeps it readable afterwards. |
| Migrate to a lakehouse | — | Yes | Large volume, reconciled table by table, then kept current with change capture. |
The full decision guide, with the economics of each choice →
Planning applications are the most demanding destination: they need complete, checked data inside a time window, and they produce plans that belong back in the ERP. Backbone treats each of them as a first-class target.
First load in weeks, then net-change loads on the planning calendar. Planned orders return to SAP or Oracle through confirmed transactions.
Technology page →Foundation loads with hierarchies and master data captured as planning MDM, reconciled on every run.
Technology page →Loads timed to the planning cycle; exceptions routed to the planner who owns the item; plans read back for execution.
Technology page →ECC or S/4HANA data into IBP, alongside data from Oracle and other systems, without an extra SAP data licence.
Technology page →Run windows on the planning calendar, control totals per table, accepted plans written back.
Technology page →Run Backbone as a service on Lima-managed AWS, in your own cloud account, or on your own servers. The same reference configurations apply everywhere, from 32 vCPU with 256 GB of memory to 128 vCPU with 512 GB. Each installation is single-tenant, runs across three availability zones, connects to SAP over a private link, and uses your single sign-on.
The subscription is sized by the estate and the capacity you run on. There is no charge per row, per connector, per run or per question, so a large migration costs the same as a small refresh on the same tier. Fixed-price entry offers give a trial a clear end point: a free extraction assessment, a four-week first load with a reconciliation report, a fixed-price migration conversion, and a per-system archive-and-decommission.
A conformance matrix lists each standard, whether it is shipped, in progress or scheduled, and the quarter it lands. Technical evaluators can answer their checklist from the page.
The SAP extraction compliance statement, the write-back audit model, and the rule that metadata may go to an external AI model while row data stays inside. Certification status is shown with dates, and reports can be requested under NDA.
Customers are anonymised until each approval to name them lands. Every figure on this site is labelled with where it comes from: estimate, lab, production or showcase estate.
Planning-data bridge across 1,000+ SAP tables into the planning suite; integration cost 70% lower than the quoted programme.
800+ tables bridged; first planning load in 8–10 weeks with reconciliation per table.
ERP-to-planning backbone in production since 2022; net-change loads on the planning calendar.
Multi-ERP consolidation and planning master data feeding the planning cycle since 2020.
All outcomes and the ROI method → · The Backbone Benchmark: method published now, results next quarter →
Backbone is the name for the pipeline, orchestration and change-capture engine inside Lima, the part that moves data and brings results back. It can be licensed on its own and inherits the platform’s catalog, lineage, quality rules and access policy either way.
You keep it. Lima tasks run inside your Airflow DAGs, and enterprise schedulers can trigger Lima jobs and receive their status back. Backbone adds the pieces those tools leave to you: deadlines on the business calendar, pause and resume on a data problem, exception records with owners, and confirmed write-back.
SAP ECC and S/4HANA, Oracle E-Business Suite and Oracle Cloud, and PeopleSoft, through each vendor’s supported interfaces. Other databases and applications connect through the 40+ connector library or the connector SDK.
Most teams start at level 1 or 2: a nightly copy into a data lake, a migration, or an archive. The planning integration is the most demanding job the engine does, and the same engine and tools carry a team there when they are ready.
By the estate and the capacity you run on, as a subscription with fixed-price entry offers. There is no charge per row, connector, run or question.
Four weeks, one dataset, one target: your ERP into a data lake or a planning application, with a reconciliation report at the end.
