What SAP and Databricks don't tell you about the "Autonomous Enterprise"

Why vendor lock-in in closed data and AI platforms costs a mid-sized company far more than a large corporation.

SAP just unveiled its “Autonomous Enterprise” at Sapphire 2026: proprietary AI agents, orchestrated inside its own ecosystem, promising a business that “runs itself.” Databricks, meanwhile, has spent months positioning its warehouse as the only serious foundation if you want to do real AI on your data.

Both pitches sound equally good. And both skip the same question — the one almost nobody asks in the sales meeting: if you want to leave in two years, what does it cost you?

That question isn’t a technical footnote. It’s the one that separates an infrastructure decision from a ten-year mortgage on how your company operates.

The problem isn’t the platform — it’s what happens after you sign

Neither platform is bad. SAP has done enterprise-grade ERP for decades. Databricks solves real large-scale data processing problems. The issue isn’t technical capability — it’s what happens once your company is inside.

When your data lives in a platform’s proprietary format, your workflows run on its engine, and your team was trained on its interface, leaving stops being a technical decision. It becomes a months-long project — sometimes over a year — just to end up, somewhere else, with roughly what you already had. That exit cost has a name: vendor lock-in. And it’s almost always the cost that never shows up in any sales proposal.

For a corporation with thousands of employees and an eight-figure IT budget, that cost gets diluted. It can absorb a two-year migration without the business grinding to a halt. For a company with 50 to 500 employees — the size where there’s real budget but no in-house data team — that same cost doesn’t dilute at all. It hits in full, and it hits once, at the worst possible moment: when the company has already outgrown what the original platform could support at a reasonable price.

What does “Autonomous Enterprise” actually mean?

SAP’s pitch is that AI agents will run entire processes — from procurement to finance — without constant human intervention. It’s an appealing promise, and, on paper, technically achievable.

What’s said less clearly is that those autonomous agents run exclusively inside SAP’s stack. It isn’t an AI layer you can move to another platform if the business decides to switch ERPs, nor one the client can freely audit or modify — it’s just another function of the ecosystem, under the same lock as everything else.

That doesn’t make the announcement bad news for everyone. For a company that already runs its entire operation on SAP, has no plans to move in the next ten years, and values having everything integrated under one vendor with 24/7 support, the offer can make real sense. The problem shows up when a mid-sized company that’s still deciding how to structure its data infrastructure adopts the same path without measuring the exit cost — simply because the name sounds like the definitive answer.

What does the Databricks warehouse actually mean?

Databricks’ argument is different but ends up in the same place: centralize all your data processing and AI on its platform to get a “single source of truth” with the performance machine learning models need at scale.

It’s a solid architecture, used by serious companies. But again: the pipelines, processing jobs, and trained models stay tied to its engine (even if part of the data sits in open formats like Delta Lake, the operational logic around it doesn’t). Switching compute providers later means rewriting much of that logic, not just moving files.

For a company processing terabytes daily that needs the specific performance Databricks offers out of the box, that trade-off can be justified. For a mid-sized company that needs to centralize data from an ERP, a CRM, a handful of spreadsheets and WhatsApp Business — the real scenario for most 50-to-500-employee companies across LATAM — it’s an oversized architecture, with an entry and exit cost that doesn’t match the problem it’s meant to solve.

The alternative: the same capability, without the lock

There’s a path that reaches the same destination — centralized data, dashboards, automation, AI applied to the business — built on open tools: standard databases, open-source processing engines, AI models that can be swapped depending on the use case instead of being tied to a single one.

The difference isn’t in what the company can do with its data — either path can automate processes, get real-time reporting, and use AI to make better decisions. The difference is in who controls what happens next: the price that can rise without notice, the feature that can be discontinued, the migration that can become mandatory the day the vendor changes strategy.

With an open stack, the company makes those calls. The client fully owns what was built and can decide whether to maintain it in-house or keep working with whoever built it — that’s the client’s decision, not a contractual clause forcing their hand.

Does investing in your own infrastructure actually pay off, or is it just technical idealism?

The most reasonable objection to all of this is: “sounds good in theory, but does building something in-house instead of buying a ready-made platform actually pay for itself?”

There’s concrete evidence that it does. dbt Labs — one of the most widely used transformation tools in open data stacks — reported in July 2026 that its customers recovered, on average, the equivalent of 58.7 full-time positions in operational capacity, worth $1.75 million a year, simply by investing in well-designed, owned data infrastructure instead of depending on manual processes or closed platforms that didn’t fit their real operation.

That number doesn’t come from a platform selling its own product — it comes from measuring the effect of having real control over your data infrastructure, regardless of which specific tools sit underneath. It’s the same logic behind choosing an open stack: it isn’t an ideological stance about free software, it’s an economic decision about who controls the long-term cost.

What this looks like at a real mid-sized company

An anonymized case that illustrates the problem with real numbers: a manufacturing company in the region, around 180 employees, contracted a cloud BI platform integrated with its ERP three years ago. The promise was the usual one — a single panel for everything, no need to build anything on the side.

It worked well while the company operated in a single country with a moderate data volume. When it opened a second plant and started selling into two more countries, both data volume and user count grew, and the licensing cost for that platform tripled within 18 months — the pricing model was tied to active users and query volume, not a fixed plan.

When the company evaluated migrating to something better suited to its actual size, it found that the reports, data models, and automations it had built over three years lived entirely inside that platform’s proprietary format. Migrating them wasn’t “exporting a file” — it meant rebuilding the business logic from scratch in another tool, with the in-house team learning a new syntax while the business kept running on duplicated reports during the transition.

The cost of that migration ended up comparable to what it would have cost to build the whole solution from scratch with open tools — except this time, they’d already paid three years of licensing before even getting started.

That’s exactly the scenario an open stack avoids — not because it’s free or magic, but because it separates the tool from the business logic: if the company grows or changes direction, you replace the piece that stopped serving it without having to rebuild everything else.

What “open stack” means in practice, service by service

It isn’t an abstract concept — it translates into concrete decisions about each piece of the infrastructure:

• Data centralization (Data Lake & Warehouse): sources (ERP, CRM, spreadsheets, WhatsApp Business, banks) are integrated on standard database engines, not on a proprietary format only one platform can read.
• Source integration (ETL): the pipelines that move and transform data stay documented and portable — they can move to a different compute engine without rewriting the business logic from zero.
• Dashboards (Business Intelligence): built on tools like Metabase, which read directly from the company’s own database — they don’t require the data to “live” inside the visualization tool to work.
• Document search (RAG) and AI agents: connect to whichever language models make sense at any given time — without being tied to a single AI provider that can raise prices or change usage terms without warning.
• Automations: run on n8n, an open tool the company can host wherever it wants, instead of depending on a workflow that only exists inside one vendor’s ecosystem.

Each of these pieces can be replaced independently if the business needs it, without dragging the rest of the system into the migration.

Comparison table: proprietary stack vs. open stack

	Proprietary stack (SAP, Databricks)	Open stack
Technical capability	High, proven at large scale	High, equivalent for 90% of mid-sized company use cases
Entry cost	Often includes licensing, consumption minimums or annual commitments	Scoped and quoted on the real project, no licensing minimums
Exit cost	High — migrating means rebuilding logic and retraining the team	Low — data and logic stay in standard formats and tools
Who controls the roadmap	The vendor	The company, with whichever provider it chooses at any point
Vendor’s own built-in 24/7 support	Yes, part of the contract	Depends on the chosen service provider, not the tool itself
Best fit for	Large companies already integrated into the ecosystem, with no migration plans	Mid-sized companies still defining their infrastructure who want to keep control

When does the proprietary stack make sense — and when doesn’t it?

Being honest about this is what separates real analysis from a sales pitch. Lock-in isn’t automatically bad — it’s a cost that’s sometimes worth paying.

It makes sense when: the company already operates with thousands of users on an ERP like SAP, and splitting off modules would cost more than staying. It also makes sense when data volume demands the specific performance a platform like Databricks delivers out of the box, and there’s no in-house team with time to run an owned architecture. In those cases, paying for all-in-one integration and support is a reasonable call, not a mistake.

It doesn’t make sense when: the company is still defining how to structure its data, has between 50 and 500 employees, and has no certainty (or need) to commit to a single vendor for the next ten years. In that scenario, adopting a closed platform “because that’s what large companies use” usually means paying for capacity that won’t get used, and buying an exit cost nobody calculated before signing.

What you can do this week

Before signing any “all-in-one” platform contract — data, AI or ERP — ask for a concrete answer to this question: if we decide to migrate in two years, how much does it cost and how long does it take? Ask for it in writing, not as a verbal estimate in the sales meeting.

If the answer is vague, or if nobody in the room wants to commit to a number, you already have the real answer to the question that actually matters.

If you already signed that contract a while back and don’t have that answer, the exercise is still worth doing: ask your team (or whoever provides your support) to document what would happen if you had to migrate tomorrow. Not to actually do it — just to know, with real numbers, how tied your operation currently is to a single vendor. That figure, even if you don’t act on it right away, is what lets you negotiate your next contract renewal better, and what warns you in time if it’s worth planning a gradual exit instead of waiting until the cost of staying becomes unsustainable.

FAQ

Is an open stack cheaper than a proprietary one?

Not always in upfront cost — sometimes a custom-built solution costs the same or more. The real difference is in exit cost: low with an open stack, potentially the single biggest expense of the whole project with a closed platform.

Does using open-source tools mean Raifen doesn’t provide support?

No. Support comes from Raifen’s team (or whichever provider the company chooses), not a generic help desk for the tool. The difference is that support isn’t mandatory forever — the company can walk away from it without losing what was built.

Do large companies also use open stacks?

Yes — many of the world’s largest data platforms (Netflix, Airbnb, Uber, among others) build their core infrastructure on open-source tools, precisely to avoid depending on a single vendor at that scale.

How do I know if my company is already locked in?

A clear sign: if nobody on your team can explain how you’d extract all your data and processes if you switched providers tomorrow, you’re already inside a lock-in — even if you haven’t felt it as a problem yet.

Does Raifen only work with open stacks?

Yes, by design. It’s the foundation of the offer: no dependency on proprietary vendors like SAP, Power BI or Snowflake, with every project scoped on its real requirements to reach the best possible estimate from day one.

What if my company already invested in a closed platform and can’t migrate right now?

You don’t need to migrate everything overnight. The most common approach is to start with the newest or least integrated piece — an additional dashboard or a specific automation, for example — built on an open stack, while the rest keeps running as-is. Over time, that proportion flips, without the risk or cost of a full migration all at once.