You're on SAP BW and Datasphere: Move to Business Data Cloud Before the 2027 Deadline and Keep Every Report Right
SAP BW 7.5 mainstream maintenance ends in 2027. Data Workers plans the move to Business Data Cloud in waves, maps every reader, tracks parity checks and holds each gate for the owner's sign-off.
Your finance and sales numbers were built in SAP BW. Process chains load ADSOs every night through ABAP routines that encode a decade of business rules, and InfoProviders feed BEx queries and SAP Analytics Cloud stories. Next to it, SAP Datasphere is where new models get built: replication flows, transformation flows, analytic models and data products. The calendar is set. SAP says SAP NetWeaver 7.5, the release under BW 7.5, "will be supported in mainstream maintenance until end of 2027", with extended maintenance offered until the end of 2030, and SAP BW/4HANA is maintained until the end of 2040. SAP calls SAP Business Data Cloud "the path forward" for on-premises BW customers: lift BW into SAP Business Warehouse, private cloud edition, turn InfoProviders into data products, and replace BW flows with Datasphere over time.
That move runs in waves, for months or years, with BW and Datasphere both live. The hard part is rarely the BW object. It is the reader nobody listed, the ABAP end routine nobody documented, and the parity check everyone agreed to run and nobody signed. Data Workers is the agentic data platform that owns that part: it plans each wave with its parity checks, maps every reader inside and outside SAP, catches drift on the reading side the night it happens, and holds the completion gate until the owner signs off.
Key takeaways
- •The 2027 date is real, and SAP's path is set. BW 7.5 mainstream maintenance ends at the end of 2027. Business Data Cloud, with BW private cloud edition, the Data Product Generator and the BW Migration Assistant, is SAP's route forward.
- •SAP moves the objects. Data Workers keeps the numbers right while they move. Each wave gets a plan, a reader map, parity checks your team runs on both sides, and a gate that stays closed until a named owner signs off.
- •Drift is caught where it lands. Metrics your team defines are recorded on the readers after each run, so a rebuilt flow that disagrees with its BW routine opens an incident before the morning call.
- •Readers outside SAP are in scope. Warehouse tables, dbt Cloud jobs and BI all appear in the reader map.
- •Start with one wave. One BW domain in its parallel run, read-only first, then one change class behind approvals.
SAP BW and Datasphere are where your SAP reporting models live. Data Workers is the gatekeeper that keeps them right through the move.
A wave asks a question wider than any BW object: who reads this InfoProvider, what must the new flow reproduce, has anyone shown that it does, and who said yes? Here is one night in a wave. This is an illustration, not a customer case.
The stack: a consumer goods company has lifted BW 7.5 into BW private cloud edition and is moving domain by domain into Datasphere. Wave 4 is sales billing. In BW, process chain ZPC_SD_BILL_D loads ADSO ZSD_BIL01, and the end routine drops pro forma invoices (billing types F5 and F8), as it has since 2014. In Datasphere, transformation flow TF_SD_BILLING rebuilds the flow on a replication flow from S/4HANA, and a custom Sales Billing data product is shared zero-copy to Google BigQuery through SAP BDC Connect. The commercial analytics team runs dbt Cloud on BigQuery; fct_sell_in feeds the Looker "Sell-in vs plan" Explore and an 08:00 scheduled delivery to distributor sales. Wave 4 is in its parallel run, planned by Data Workers with its parity checks; fct_sell_in is listed as a reader that stays on the BW extract until sign-off. Tickets live in Jira Service Management; alerts go to Microsoft Teams.
| Time | System | What happens |
|---|---|---|
| Wed 16:00 | GitHub + dbt Cloud | Ahead of a Friday demo, an analytics engineer merges a change that repoints fct_sell_in from the BW extract to the Sales Billing data product in BigQuery |
| Thu 15:30 | Wave 4 tracker | Day 2 parity results logged: row counts match for the billing types both sides carry; net billed value runs 7.6% high on the Datasphere side for sales organizations DE01 and AT01. Open, for Friday triage |
| Fri 00:40 | SAP BW PCE | ZPC_SD_BILL_D loads ZSD_BIL01; the end routine drops F5 and F8. Green |
| 01:05 | SAP Datasphere | TF_SD_BILLING builds the Sales Billing table with no billing-type filter, so pro forma invoices stay in. Task chain green |
| 02:00 | dbt Cloud + BigQuery | Job commercial_nightly builds fct_sell_in from the shared data product. Every dbt test passes |
| 02:15 | Data Workers | The job's last step records the two wave 4 metrics with monitor_metrics: net billed value for DE01 and AT01 reads 7.9% above baseline, and billing types F5 and F8 appear against a baseline of zero. Incident opened |
| 02:20 | Data Workers | trace_cross_platform_lineage and blast_radius_analysis over BigQuery and the dbt artifacts: fct_sell_in feeds three models, the Looker Explore and the 08:00 delivery. It is a wave 4 reader that moved before the gate |
| 02:24 | Data Workers | diagnose_incident joins the new F5 and F8 rows, the day 2 parity gap in the same two sales organizations, and the BW inventory entry for ZSD_BIL01, whose end routine excludes pro forma types. get_incident_history finds no earlier case |
| 02:30 | Jira SM + Teams | create_jira_sm_ticket opens the ticket with the diagnosis, send_teams_alert posts a card, and the approval request goes by email to the wave 4 owner, the BW lead. It recommends pausing the 08:00 delivery |
| 06:35 | Looker | The Looker owner pauses the scheduled delivery |
| 06:40 | Spellbook | The BW lead reviews three proposals: a dbt diff pointing fct_sell_in back at the BW extract, a change request for the Datasphere developer adding the billing-type filter (citing the BW routine), and a new parity check on documents per billing type. She approves the first and third and assigns the second. The gate stays closed |
| 06:55 | dbt Cloud | After merging the revert, the engineer queues the approved rerun in dbt Cloud, recorded in Spellbook |
| 07:25 | Data Workers + BigQuery | Metrics back in band, F5 and F8 gone, and run_quality_check passes volume on fct_sell_in. The delivery resumes; the 08:30 sell-in call sees the right number |
| Tue 09:00 | Spellbook + Jira SM | Filter deployed Monday, parity rerun for days 1 to 5 within tolerance. The BW lead signs the gate; the receipt (cause, approvals, revert, rerun, parity results, sign-off, undo) is linked from the ticket, and "net billed value excludes pro forma billing types F5 and F8" lands in the Context Wizard graph as an approved fact |
Every system did its job. The problem was a rule that lived in ABAP, a reader that moved early and a parity gap waiting for triage. Data Workers connected the three overnight, kept the gate shut and left a record the auditors and the BW lead can both read.
| Job | What SAP BW and Datasphere do | What Data Workers does |
|---|---|---|
| The model | Hold InfoProviders, queries, analytic models and data products with SAP's semantics | Keeps one context graph of every reader around them, inside and outside SAP, with owners |
| The move | Lift BW into private cloud edition; the Data Product Generator makes data products; the BW Migration Assistant translates data flows | Plans each wave with its parity checks, maps the readers and holds the completion gate for the owner's sign-off |
| The run | Process chains and task chains report whether each step ran | Records the metrics that define right on the reading side |
| The diagnosis | Monitors show the step that failed | Joins metric, parity log, lineage and BW routine into one cause when every step is green |
| The fix | Changes run through SAP modeling and transports | Proposes each change to its owner and records the approved dbt Cloud rerun the owner queues |
| The proof | Keeps object and load history | Writes a receipt per change and per gate |
Why doesn't SAP BW and Datasphere just do this itself?
Because SAP built the right tools for its job: getting your BW investment into Business Data Cloud with as little disruption as possible. BW private cloud edition gives BW a supported cloud home. The Data Product Generator turns InfoObjects, ADSOs, CompositeProviders and queries into data products, and the BW Migration Assistant translates BW data flows into Datasphere artifacts with AI. Datasphere is what SAP calls "the knowledge core", and Joule Agents "draw on SAP Business Data Cloud's knowledge core to autonomously orchestrate complex workflows". SAP also offers a free system assessment and completed its acquisition of Dremio on July 6, 2026. Each piece makes the move into SAP's platform work.
What sits outside that platform is a different product. The reader of a BW InfoProvider might be a dbt model in BigQuery, a Looker Explore or a Python job, owned by teams SAP never sees. Proving a wave is done means parity tracked per wave and a sign-off that names a person. Keeping numbers right during the parallel run means watching the reading side, tracing a gap across SAP, the warehouse and BI, and proposing a fix in a repository SAP doesn't own. A platform vendor that changed another team's dbt project would carry liability it was never designed for. Data Workers is built for that: blast-radius scoping, named approvals, a recorded undo and receipts. See is it safe to let AI agents change production data.
Every tool owns a slice. Data Workers covers the whole lifecycle
SAP BW and Datasphere own the SAP reporting models. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the SAP estate already there.
| Stage | Data Workers | SAP BW and Datasphere | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 7 | BW InfoObjects and Datasphere's semantic models carry rich SAP meaning inside SAP. Data Workers keeps one context graph across SAP and every system that reads it. |
| Analytics & Insights | 8 | 8.5 | SAP's home stage: BW queries and Datasphere analytic models behind decades of finance and sales reporting. Data Workers answers data questions from governed definitions on top. |
| Data Quality | 8 | 5 | Transformation routines and DTP error handling catch what each load rejects. Data Workers records the metrics that define right on the readers after every run. |
| Observability & Incidents | 8.5 | 3 | Process chain and task chain monitors report whether each step ran. Data Workers diagnoses the data incident across SAP, the warehouse and BI, and verifies the fix. |
| Pipelines & Ingestion | 8.5 | 6.5 | Process chains, replication flows and transformation flows move SAP data well. Data Workers queues approved reruns through the orchestrator on the reading side. |
| Schema & Migration | 8 | 6 | SAP's tools move BW into Business Data Cloud: the Data Product Generator and the BW Migration Assistant. Data Workers plans the waves, maps the readers and holds the gate. |
| Governance & Access | 8.5 | 7 | Analysis authorizations and Datasphere spaces govern access inside SAP. Data Workers routes every data change to a named approver across systems. |
| Security & Privacy | 8 | 6 | Mature SAP security and authorizations. Data Workers leaves a receipt on every data change across systems. |
| Cost / FinOps | 8 | 3 | Capacity units meter Business Data Cloud. Data Workers reads spend where SAP data lands: Snowflake down to the dbt model, BigQuery job spend as an account total. |
| MLOps & Models | 7.5 | 4 | SAP Databricks sits next to BW data in Business Data Cloud. Data Workers keeps the data under those models healthy. |
How SAP BW, Datasphere and Data Workers work together
People keep asking questions in Joule, their assistant or a coding agent. Spellbook Data Catalog (in preview) is where the BW lead and the data team look: each wave's plan, its parity results, each proposed change, who approved it and how to undo it. Underneath, Context Wizard keeps one governed context graph, the Data-Agents Swarm (20+ specialist agents) does the work, and the Autonomous Data-Conductor runs each fix end to end.
How Data Workers connects today. Data Workers connects to SAP BW and Datasphere over SAP's APIs today: the Datasphere consumption API lists spaces and exposed assets, read-only by SAP's design, with a technical user your basis team scopes, and the Data Migration agent works from the object inventory your BW team exports (InfoProviders, routines, queries, where-used lists). Where SAP data lands, Data Workers reads natively: BigQuery, Snowflake, Databricks, dbt Cloud, Looker and Tableau (read), Jira Service Management, Teams and more (integrations). An MCP server for SAP that your team runs in its own client sits next to Data Workers there; Data Workers' detection and verification rest on what its own connectors read.
What Data Workers does in a wave. It plans each wave with its parity checks: which InfoProviders move, which readers each has, which comparison queries prove the new flow matches, and who signs off. It proposes the queries your team runs in BW and Datasphere, tracks the results per day and holds the completion gate. Translation stays with the BW Migration Assistant and your developers; Data Workers makes sure the result is the same number. On the reading side, generate_migration writes warehouse schema changes with rollback SQL for the owner to apply. A migration in 4 to 8 weeks instead of 6 to 12 months is a design target. More in migration agents for legacy modernization.
Setup for the data team. Every Data Workers agent is an MCP server. Follow the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry to your client.
// Example: Data Workers agents for a BW wave in a Claude Desktop-style mcpServers block
{
"mcpServers": {
"dw-incidents": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-incidents"] },
"dw-catalog": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-context-catalog"] },
"dw-quality": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-quality"] },
"dw-schema": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-schema"] },
"dw-connectors": { "command": "/path/to/dataworkers-claw-community/start-agent.sh", "args": ["dw-connectors"] }
}
}List the tools with your client's own command (for example /mcp in Claude Code). In production the agents run in your infrastructure and hold the credentials and model key. Your data stays in your systems; the hosted Conductor sees workflow metadata only (where does our data go).
One wave, L0 to L4, set per domain:
- •L0 manual. Parity lives in a spreadsheet, readers in someone's memory, and the gap surfaces at the 08:30 call.
- •L1 observe. Data Workers records the wave's metrics, flags the gap at 02:15 with cause and blast radius, and shows which readers moved early. Nothing changes.
- •L2 propose. It proposes the revert, the Datasphere change and the new parity check. A named owner approves; an unanswered request expires and escalates, never auto-grants.
- •L3 act reversibly. For a class with a clean record, such as queuing an approved rerun, it carries out the reversible step, verifies it and sends any failed check to a person.
- •L4 autonomous. In a scoped domain the fix is waiting for the owner before the first business user opens the report. Gate sign-off always stays with a person.
More in who owns the agents, how approvals work and autonomy levels L0 to L4.
What changes for your team
- •Every wave closes with proof. The BW lead signs a gate backed by tracked parity results, so "is wave 4 done?" has one answer.
- •The ABAP routine stops being folklore. Rules found in BW routines become approved facts in the Context Wizard graph, so the next Datasphere rebuild starts from them.
- •Readers outside SAP stop surprising the SAP team. They are in the reader map before the wave starts.
- •Old extracts retire on evidence. Once a gate is signed, retiring the BW extract is proposed to its owner after a dependency check.
For the business-semantics side of Business Data Cloud, where data products feed models in Databricks and Snowflake, read you're on SAP Business Data Cloud. For Dremio, now part of SAP, see you're on Dremio; for the Looker side of this estate, you're on Looker.
Keep SAP BW and Datasphere, or consolidate?
Keep SAP BW and Datasphere if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For most SAP-run companies Business Data Cloud is where BW goes; you're on Teradata shows the same wave-and-gate loop for a move to Snowflake. What teams consolidate is the tooling around the move: parity spreadsheets and runbooks that end with "ask finance to check". Weighing a build on SAP's APIs and a coding agent? Reading an API is the easy part; the reader map, the gate, approvals and receipts are the work (build it ourselves with Claude Code and MCP servers).
The case for your CFO
The outcome. The BW move finishes on a plan the business can follow, and finance and sales numbers stay right in every wave. Each domain closes with tracked parity results and a named sign-off, so nobody finds a broken number at quarter end.
The risk story. At L0 and L1 agents only read: SAP through read-scoped APIs, the warehouse and BI through native connectors. At L2 they propose and a named person approves; an unanswered request expires and escalates. At L3 they act on reversible steps inside domains you open; L4 is a later choice per domain. No agent can promote its own work, gate sign-off stays with the owner, and an org-wide stop halts all autonomous dispatch. Every change carries a receipt: what changed, who approved it, the blast radius and how to undo it. Nothing migrates to start.
Why now. SAP NetWeaver 7.5 leaves mainstream maintenance at the end of 2027. Every slipped month means running two systems; every rushed wave risks a wrong number in a board pack.
The first win. One BW domain in its parallel run, readers mapped, metrics recorded and the gate held for sign-off.
What stays the same. SAP BW, Datasphere, your SAP partner, transports, warehouse, dbt project, BI and on-call rota. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "SAP moves our BW objects into Business Data Cloud; Data Workers makes sure every report shows the same number in each wave, and nothing is called done until the owner signs off."
Getting started
Start with a pilot. Pick the BW domain in or nearest its parallel run, export its object inventory, give Data Workers read access to Datasphere and to the warehouse and BI tools that read SAP data, agree the two or three metrics that define the same number, and let Data Workers plan the wave and hold its gate at L1 and L2. Plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
When does SAP BW maintenance end? SAP states that SAP NetWeaver 7.5, the release under BW 7.5, is in mainstream maintenance until the end of 2027, with extended maintenance offered until the end of 2030. Lifting to BW private cloud edition carries maintenance support until the end of 2030, and SAP BW/4HANA is maintained until the end of 2040. Check your contract and SAP's maintenance planning for your release.
Does Data Workers translate BW objects or ABAP routines? No, by design. SAP's BW Migration Assistant and your developers translate BW data flows into Datasphere. Data Workers plans the waves, maps the readers, tracks the parity checks that prove the new flow matches, and holds the gate.
Does Data Workers compare BW and Datasphere data itself? It proposes the comparison queries your team runs on both sides, tracks the results per wave and holds the gate until the owner signs off. On the reading side it records the metrics your team defines, which is how the incident above surfaced at 02:15.
How does Data Workers connect to SAP BW and Datasphere? Over SAP's APIs today, plus the BW object inventory your team exports. Where SAP data lands, BigQuery, Snowflake, Databricks, dbt, Looker and Tableau connect natively.
We plan to stay on BW private cloud edition until 2030. Is this still useful? Yes. Every domain you move before then is a wave, and the same reader-side checks cover BW-fed and Datasphere-fed data alike.
Will Data Workers change anything inside SAP? It proposes. Changes inside SAP go to their SAP owner as a change request and run through your transports; reading-side changes arrive as diffs for the owner to merge, and reruns queue through your orchestrator after approval.
Sources
- •SAP, SAP Business Data Cloud product page (components; FAQ "the path forward for current on-premises SAP Business Warehouse application customers"; Joule Agents), https://www.sap.com/products/data-cloud.html (checked Oct 3, 2026)
- •SAP, Modernize SAP BW with SAP Business Data Cloud (free assessment, data product generator), https://www.sap.com/products/data-cloud/sap-bw-migration.html (checked Oct 3, 2026)
- •SAP, SAP Datasphere in Business Data Cloud ("the knowledge core"), https://www.sap.com/products/data-cloud/datasphere.html (checked Oct 3, 2026)
- •SAP, SAP Business Warehouse in Business Data Cloud, https://www.sap.com/products/data-cloud/business-warehouse.html (checked Oct 3, 2026)
- •SAP Architecture Center, Modernizing SAP BW with SAP Business Data Cloud (BW private cloud edition support to end of 2030, BW/4HANA private cloud edition to 2040, Data Product Generator, BW Migration Assistant; last updated May 12, 2026), https://architecture.learning.sap.com/docs/ref-arch/6550e4 (checked Oct 3, 2026)
- •SAP Community, SAP NetWeaver 7.5 Maintenance Strategy (mainstream until end of 2027, extended until end of 2030, BW/4HANA until end of 2040), https://pages.community.sap.com/topics/abap/netweaver-maintenance-strategy (checked Oct 3, 2026)
- •SAP News, SAP Completes Acquisition of Dremio (Jul 6, 2026), https://news.sap.com/?p=243771 (checked Oct 3, 2026)
- •SAP Help Portal, What's New in SAP Business Data Cloud (SAP BDC Connect for Google BigQuery GA Aug 4, 2026), https://help.sap.com/docs/SAP_BUSINESS_DATA_CLOUD/cbce6bb04a6e4546aa4a44e1daa55599/ab4b1ecedd244f068756dff01b7104d6.html (checked Oct 2, 2026)
- •SAP Help Portal, SAP Datasphere: Consuming Data via the OData API, https://help.sap.com/docs/SAP_DATASPHERE/43509d67b8b84e66a30851e832f66911/7a453609c8694b029493e7d87e0de60a.html (checked Oct 2, 2026)
- •Data Workers, client setup, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers open-source repository (tool registrations in dw-incidents, dw-context-catalog, dw-quality, dw-schema, dw-connectors), https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)