Own What’s Next: How to Modernize Your Data Foundation Without Trading One Lock-in for Another

This article was coauthored by Ava Chawla, Global Field CTO Leader, EDB; and Andreas Prins, Global Head of Sovereign Solutions, SUSE.

In nearly every conversation we have about data sovereignty, the first word out of someone’s mouth is residency. Where does the data physically sit? That’s the question executives are trained to ask, and it’s the wrong question to stop at. We recently joined a webinar together, Own What’s Next: Modernize Your Data Foundation for the AI Era, and we kept circling back to this: Residency is one input into sovereignty, not the whole answer. 

The same question shows up wherever your data foundation has quietly stopped being yours: in the sprawl of point solutions you now have to stitch together, in the cost of moving data to wherever your AI needs it, and in who actually orchestrates the agents acting on it. Real control over your data and infrastructure is the bigger conversation, and it’s one enterprises need to have right now.

Why now

Five pressures are converging on data teams at once: rising licensing and proprietary costs; AI agents that need fresh, governed operational data instead of a batch job from two hours ago; governance and security demands expanding as the agentic threat landscape grows; data sprawl that worsens with every bolted-on point solution; and, for organizations further along in their AI journey, creeping token costs. None of these is new on its own. What’s new is that they’re arriving together, and the decisions you make about your data foundation today either unlock your options tomorrow or foreclose them.

Why this matters

It’s tempting to treat a legacy database migration as a simple swap. Replace Oracle or DB2, check the licensing-savings box, move on. We understand the instinct, but a narrow swap solves today’s problem while silently building tomorrow’s. The moment you need in-database inferencing or have to bolt on a specialized vector engine, or your agents need near–real-time access to transactional data through a change-data-capture pipeline you now have to build and maintain, you’ve reintroduced the complexity you thought you’d eliminated. That’s lock-in too; it’s just operational instead of contractual.

The alternative is designing for control from the start, across four dimensions: your data (open standards that extend from transactional into analytics and AI, rather than a new silo for every capability), your cost (predictable growth versus a bill you didn’t design for), your AI (your data is your crown jewel, because tomorrow’s leading companies will be the ones that actually own and govern the data their AI depends on), and your infrastructure (the ability to run anywhere, on terms you set).

Why EDB + SUSE

This is where our two companies meet the same problem from different layers. EDB’s job is the data layer, meaning a governed, open PostgreSQL foundation, EDB Postgres AI, that extends across transactional, analytics, and AI workloads without forcing you to stitch together a separate vector database, warehouse, and governance layer. SUSE’s job is everything underneath, which means SUSE Rancher Prime for independent, multi-cloud Kubernetes management and SUSE AI Factory for the observability, security, and access to validated application blueprints that a data-heavy AI platform needs.

The deeper thing we agree on is a framework for what control actually means, and it isn’t residency. It comes down to four abilities:

• Exit: Can you leave a platform in days, not months?
• Own: Can you patch and redeploy the software yourself?
• Audit: Can you audit not just the code but the entire supply chain that moved it from a public repository into your environment?
• Operate: Can your own people, or a partner under the same jurisdiction, actually run it?

If you can’t answer yes to all four, you don’t have an exit strategy. You have an assumption.

This also isn’t a uniform global conversation. In Canada, the Middle East, and especially Japan, organizations talk less about sovereignty in the abstract and more about sovereign AI specifically—which is where this is headed everywhere else, too.

How the migration works in practice

For organizations moving off Oracle, EDB’s compatibility layer typically gets you to roughly 95% compatibility out of the gate, concentrating real engineering effort on a narrow slice of schema changes rather than a full rewrite. For other legacy platforms, EDB offers agentic migration tools for assessment and schema conversation. 

The path to getting started begins with an honest assessment of what actually needs to move, not a line-by-line feature comparison between your legacy environment and your destination. That’s a trap we see constantly, as teams try to match every feature one-to-one when most environments actively use only 20%–30% of what they’re paying for.

Sequencing matters, too. Start with noncritical, net-new workloads to build operational muscle before anything mission critical is on the line. We’ve seen what happens otherwise: One team started with a workload they only later realized was among the most critical in the estate, and they had to pivot mid-project.

The results are concrete. A multi-billion-dollar global payment processor, operating in a highly regulated, always-on environment, moved to Postgres^® using CloudNativePG on Rancher and saw more than a 2x improvement in database operations, including rolling security patches with no downtime window and backups moved to object storage for efficiency. Running Postgres in a containerized architecture is not new, and we see it across the globe. For example, Intesa Sanpaolo, Italy’s largest bank, made a move to Postgres using CNPG. 

How do you tell a real lock-in exit from just switching vendors?

If you take one practical test from this, let it be the one we were asked directly during the webinar: How do you tell the difference between getting out of vendor lock-in and just trading one vendor for another? Look for genuine openness, in both the software and the standards it’s built on, so workloads remain portable. Then ask directly: Could you leave for another vendor tomorrow, with support behind you the whole way? If the honest answer is no, you haven’t solved lock-in. You’ve relocated it.

Modernize once, carry both

We like to say, “Modernize once, carry both.” The foundation you build today should carry the applications you’re running now and the AI workloads you haven’t scoped yet, without calling for a second modernization project later. That also means rethinking a trade-off that’s shaped architecture decisions for a decade. We’ve optimized almost everything for economic efficiency. It’s time to weigh economic security just as heavily. What does it actually cost you when a system goes down, a vendor changes the terms, or a model needs data you can’t govern?

If this is live for your organization right now, the next step is the one we closed the webinar with: a joint EDB and SUSE architecture workshop, where we map your applications, data, and deployment requirements onto this model directly. 

Learn more about EDB and SUSE at www.enterprisedb.com/partners/SUSE.

Click here to schedule a workshop.