SAP’s partnership with Databricks, launched in February 2025 and expanding steadily through 2026, has been described by at least one industry analyst as the most important platform innovation SAP has made in twenty years. For organisations already running SAP Business Technology Platform, the more immediate question is not how impressive the technology is, but how SAP Business Data Cloud is actually licensed, and why it sits commercially outside the BTP estate most customers already understand.
Reading the Announcement Correctly the First Time
It is worth being precise about the timeline here, since the partnership has evolved meaningfully since its initial announcement. SAP and Databricks announced the partnership on February 13, 2025, with SAP Business Data Cloud entering a controlled general availability release in the first quarter of that year for selected customers, followed by a staged regional rollout across AWS, Azure, and Google Cloud through the remainder of 2025. Treating this as a brand-new 2026 announcement, rather than a maturing platform now well into its second year of customer deployments, leads to an inaccurate picture of how proven or unproven the underlying technology actually is at this point.
What SAP Business Data Cloud Actually Bundles
SAP Business Data Cloud combines several previously separate products into a single managed SaaS offering. BARC’s independent analysis of the announcement lists the components as an object store built on SAP HANA Data Lake Files, SAP Databricks for data engineering and AI and machine learning tooling, SAP Datasphere, SAP BW or BW/4HANA as a hosted option, SAP Analytics Cloud, and Joule, SAP’s AI assistant, alongside a continuously expanding set of predefined data products and insight apps.
This bundling is deliberate and commercially significant. SAP Analytics Cloud and SAP Datasphere are no longer sold as separate products for customers adopting BDC, meaning organisations already licensing either one independently need to understand exactly how their existing entitlements map onto the new combined offering before assuming continuity of cost or capability.
The Financial Services and Vertical Data Angle
Beyond the general architecture, part of what makes BDC commercially interesting is SAP’s continued expansion of predefined data products spanning finance, procurement, supply chain, and human capital data drawn directly from S/4HANA, SAP Ariba, and SAP SuccessFactors. Customers evaluating the platform should ask specifically which of these predefined data products actually map to their own industry and process footprint, since the value of predefined content varies enormously depending on how closely an organisation’s actual configuration matches SAP’s standard data model assumptions.
Organisations running heavily customised SAP landscapes, the same customers who would generally lean toward RISE over GROW in the ERP conversation, are also the ones most likely to find SAP’s predefined data products a weaker fit for their specific data structures. This is not a reason to avoid the platform, but it is a reason to pilot the predefined content against real internal data before committing to a full-scale rollout, rather than assuming the marketing materials translate directly into immediate value for a non-standard implementation.
A Genuinely Different Licensing Model
Business Data Cloud does not sit inside the BTP Enterprise Agreement that many organisations already use to manage their broader platform consumption. It is licensed as its own subscription, metered through Capacity Units allocated on a monthly basis, and no separate Databricks licence is required since Databricks capability is included within the BDC subscription itself.
This distinction matters more than it might first appear. An organisation with an existing, well-negotiated BTP Enterprise Agreement cannot simply assume BDC consumption draws down against that same committed pool. It is a parallel commercial relationship with its own capacity unit economics, and treating it as an extension of an existing BTP deal rather than a separate negotiation is one of the more common early missteps organisations make when adopting the platform.
Why SAP Chose a Partner Instead of Building Alone
The rationale behind bringing in an external partner rather than building equivalent capability internally is worth understanding, because it shapes what customers can reasonably expect from the relationship going forward. TechTarget’s coverage of the launch quotes SAP’s head of product engineering describing the core problem directly: many organisations have run hundreds of proof of concepts on their data but have not been able to get them into production, or have not seen the adoption needed to realise real value. Databricks brings the data engineering and AI tooling maturity SAP judged faster to license than to build from scratch.
Analyst commentary from the same coverage frames the strategic shift plainly, describing SAP as moving away from developing every single technology component in the data and analytics stack itself, and instead focusing on its core strength of business process knowledge while partnering for the underlying platform technology. That is a meaningful change in direction from a vendor that has historically built or acquired most of its own stack, and it has direct commercial consequences for how BDC gets priced and packaged compared to SAP’s traditionally more vertically integrated products.
The Lock-In Question Customers Should Ask Upfront
Independent analysis has been candid about the trade-offs this creates. BARC’s assessment notes that Business Data Cloud can currently only be purchased through SAP, meaning existing Databricks customers wanting SAP integration still require a BDC subscription from SAP rather than being able to procure the combined capability directly from Databricks, which limits procurement flexibility. The same analysis flags that SAP’s platform bundles analytics, semantics, data integration, and storage into a single ecosystem, which is comprehensive but also reduces the flexibility to replace individual components later without disrupting the whole.
This is not a reason to avoid the platform, but it is a reason to negotiate the initial agreement with future flexibility explicitly in mind rather than assuming it can be renegotiated easily later. Questions worth raising before signing include how data portability works if the organisation later wants to reduce reliance on any single component, and what the actual exit path looks like if Databricks itself changes ownership, a live possibility BARC’s analysis raises given the company’s fundraising activity and eventual IPO plans.
Where the Cost Case Is Genuinely Strong
None of this undercuts the genuine commercial appeal of the platform for the right customer profile. Organisations already paying for high HANA-based data warehousing costs may see real reduction potential from the introduction of a lower-cost object store layer, though the actual savings depend heavily on specific licensing models and discount policies negotiated at signature rather than being automatic.
The strongest cost case tends to belong to organisations running both SAP and non-SAP data platforms in parallel today, since predefined SAP data products delivered through BDC reduce the custom integration work that market has historically required. Organisations that have already invested heavily in rebuilding their own data semantics independently of SAP’s predefined content are likely to see comparatively less incremental value from the predefined layer, even while still benefiting from the underlying Databricks engineering capability.
Building a Realistic Adoption Timeline
Organisations evaluating BDC should also build a realistic internal adoption timeline rather than assuming the platform delivers immediate value from day one of the subscription. Even with predefined data products reducing much of the traditional data engineering burden, connecting BDC meaningfully into existing AI and analytics initiatives, training internal teams on the Databricks tooling now embedded in the platform, and validating predefined content against real organisational data all take genuine implementation time that should be reflected honestly in any business case presented internally.
Underestimating this timeline is a common pattern with any newly launched platform generating significant vendor and analyst enthusiasm, and BDC is no exception. Building a phased internal rollout plan, starting with a single well-scoped use case before expanding platform-wide, tends to produce a more defensible business case than committing to enterprise-wide adoption based on the platform’s marketed capabilities alone.
Comparing BDC Against a Fully Independent Data Stack
Some organisations, particularly those with mature internal data engineering capability already invested in a non-SAP cloud data platform, will reasonably ask whether BDC is worth adopting at all versus continuing to extract SAP data into an existing independent stack. That comparison deserves an honest answer rather than a default assumption in either direction. BDC’s genuine advantage is the predefined data products carrying business context and semantics that would otherwise require significant internal engineering effort to replicate. An organisation that has already built and refined that extraction and modelling layer over several years may find the marginal value of BDC’s predefined content considerably lower than an organisation starting that data engineering effort from scratch today.
What Existing BW Customers Need to Watch
Customers running older SAP BW versions, particularly 7.5 and earlier, have a specific consideration worth flagging separately. Moving a BW system into BDC offers an extended maintenance runway through 2030 and a genuine modernisation path, but the commercial detail that remains genuinely unresolved is how SAP will prevent BW and Datasphere customers who have already invested in analytics frontends from effectively paying twice as they transition into the new bundled structure. Raising this directly during negotiation, rather than assuming the migration path is commercially neutral, is a reasonable and increasingly common request.
The Broader Signal for SAP’s Platform Strategy
Business Data Cloud is also worth watching as a leading indicator of how SAP intends to handle the rest of its platform portfolio going forward. Partnering with a best-of-breed vendor rather than building every layer in-house is a meaningfully different posture than SAP’s historical approach, and it raises a reasonable question for any customer relationship spanning multiple SAP platform products: which other parts of the BTP estate might see similar partner-based restructuring over the coming contract terms, and what would that mean for existing negotiated pricing on those adjacent products. Raising this question directly with an SAP account team during any BDC negotiation, rather than assuming the current platform boundaries are permanent, is a reasonable and increasingly common line of inquiry.
A Note on Vendor Concentration Risk
Bringing Databricks this deeply into the SAP data layer also raises a legitimate vendor concentration question worth naming explicitly during procurement risk review. An organisation adopting BDC is now commercially dependent on a three-way relationship between itself, SAP, and Databricks, rather than a straightforward two-party vendor relationship. Building this dependency into standard vendor risk assessments, alongside the usual SAP-specific risk review, ensures the additional layer of complexity gets proper visibility rather than being absorbed silently into the existing SAP risk category where it does not entirely belong.
Conclusion
SAP Business Data Cloud represents a genuine strategic shift in how SAP builds and prices its data and analytics stack, moving toward partnership rather than in-house development and toward a metered, capacity-based commercial model that sits outside the BTP agreements most customers already understand. That shift brings real capability, but it also introduces licensing structures, lock-in considerations, and migration questions that a well-prepared negotiation should address directly rather than discover after signature.
Treating BDC as simply an add-on to an existing BTP relationship, rather than as the separate, evolving commercial arrangement it actually is, is the single most common way organisations end up with cost or flexibility surprises once the platform is already embedded in their data architecture.
