Full-history migration from SAP and Oracle into Snowflake, Databricks, Microsoft Fabric or S3, with record counts and control totals proved for every table — then change-data capture keeps the lakehouse current, minutes behind the source. Lima Backbone is the SAP-aware ingestion layer that sits beside your lakehouse.
A migration job splits into task threads, and each thread runs query workers against a partition of a table. The cluster grows from 32 to 128 vCPU for the initial load and shrinks again afterward, so the capacity you pay for follows the work.
One job per table group, threads per table, workers per partition. The scheduler keeps every core busy and the source system inside the load limits your Basis team sets.
Every partition checkpoints. A network drop or a source timeout reruns one partition, and the rest of the load carries on.
Read limits, time windows and throttling per source keep the ERP responsive during the day; the heavy partitions run in the window you choose.
The tier sets the ceiling; there is no charge per row or per table moved, so a full-history migration costs the same as a quiet month at the same tier.
Structure of the report Lima produces for every migration; the figures are illustrative.
| Table | Source rows | Loaded rows | Variance | Control total | Status |
|---|---|---|---|---|---|
| MARA · MARC | 2,914,220 | 2,914,220 | 0 | — | Reconciled |
| STPO · STKO | 18,406,113 | 18,406,113 | 0 | qty 1.20 × 10⁹ | Reconciled |
| EKKO · EKPO | 1,204,881 | 1,204,878 | 3 → owners | net value matched | 3 exceptions |
| VBAK · VBAP | 6,102,447 | 6,102,447 | 0 | qty matched | Reconciled |
| BSEG partitioned by period · 132 partitions | 1,204,118,930 | 1,204,118,930 | 0 | amount matched per period | Reconciled |
| Target | Lands as | Status |
|---|---|---|
| Snowflake | Native Snowflake tables, loaded in parallel and registered in your catalog | Shipped |
| Databricks | Delta tables in Unity Catalog | Shipped |
| Microsoft Fabric | Fabric Lakehouse tables in OneLake | Shipped |
| S3 and object storage | Parquet, partitioned, readable by any query engine | Shipped |
| Iceberg and Delta on object storage | Open table formats written directly to storage, for engines that read them without a platform in between | Scheduled · standards plan |
The signed reconciliation report replaces the spot checks most migrations rely on.
Table reads, CDS views and change-data capture, which SAP keeps open; the same pipelines carry across the S/4HANA move.
Capacity-based subscription, so a 4 TB history costs the same as a nightly delta at the same tier; your lakehouse compute stays for analytics.
Change-data capture with deletes applied and late rows replayed keeps the lakehouse current.
Planning loads, write-back to the ERP, archiving and replication run on the same platform afterward.
Native tables in your platform and Parquet on your storage; readable without Lima from day one.
One engine underneath every page in this family. It reads from any source and writes to any target, runs batch loads or change-data streams, handles a nightly delta or a multi-terabyte migration, and is licensed by capacity, so the bill stays the same however many rows move. Lima's fabric answers questions on data in place; Lima Backbone moves, transforms and returns data on a deadline. When to federate and when to pipeline · The Backbone hub.
The largest documented run is about 220 million rows across 615 tables in roughly 30 minutes on 64 vCPU (estimate), with 80 GB a day moved in production. The Terabyte Proof-of-Scale runs on your own largest tables so the number you see is yours.
Read limits, time windows and throttling are set per source. The heavy partitions run in the window your Basis team approves.
The variance becomes an exception with an owner and a reason. The affected partition reruns from its checkpoint, and the report stays open until every table matches.
Yes. Lima is the SAP-aware ingestion layer beside the lakehouse; other sources can continue as they are, and the fabric reads the lakehouse live either way.
Timestamps, change pointers or triggers, depending on the table. Log-based capture on the HANA database by third-party tools is restricted by SAP, so Lima uses application-level methods.
Lima's extraction methods sit outside the ODP RFC interface, so the migration is unaffected by the December 2026 change. The exit page explains the note.
Two weeks on your largest table set: terabytes moved, rows per minute, reconciliation variance, and cost per terabyte beside the metered alternative you run today.
