The data layer is moving. Most enterprises are moving with it.
Sovereignty requirements, agentic workloads, and specialized AI clouds have changed what a database has to do and where it has to run. Learn about the paths, the tooling, and honest effort estimates for migrating off of platforms that were built for a different kind of work.
Three changes happened at once.
It's not that the databases are old; it's that the work is changing shape faster than the platforms underneath it.
1. Sovereignty stopped being a policy question.
Where data sits, who can reach it, and which jurisdiction governs it are no longer just questions for procurement paperwork, they're essential to the architecture. In EDB's global research, 24% of enterprises describe sovereignty as mission-critical today, and 61% expect to within three years. A platform that constrains where a workload can run is now constraining the business.
2. The data platform and the AI platform converged.
Agents read and write operational data. Vector search sits next to transactions rather than in a separate system. Retrieval happens against the system of record. This convergence is why 95% of enterprises say they intend to be their own AI and data platform within three years—and its requirements are different from those most estates were architected against.
3. Compute moved somewhere new, again.
Portability has stopped being a procurement preference and become an operating requirement. Hybrid estates, sovereign regions, and now neoclouds (the specialized GPU providers where a growing share of AI workloads actually runs): Each of these is yet another place where the data layer has to be able to follow.
It isn't one platform. It's a pattern.
If planning a migration feels unusual—it isn't. Consider the following four dated, public events that occurred in under three years, across four different vendors:
When | Platform | What happened |
|---|---|---|
May 2024 | Greenplum® | Tanzu by Broadcom moved future releases to a closed-source model and archived the public repositories read-only. Greenplum 7.0.0, September 2023, was the last major open source release. |
Sept 2025 | MySQL® | Oracle® cut around 70 senior engineers from the core MySQL development team. In February 2026 a Percona-led open letter asked Oracle for an independent MySQL foundation. |
2026 | Crunchy Data | Acquired by Snowflake®, removing an independent Postgres vendor from the market. |
Dec 2027 | SAP® ASE 16.0 | End of mainstream maintenance, per SAP's published schedule. ASE 16.1 runs to December 2030. |
Each of these events is a vendor's own published action or a third-party reported event, not a prediction. Individually they're ordinary industry motion. Together they're the reason migration planning has become a standing agenda item rather than a project.
Start where you are.
What platform are you migrating from? Follow the links below to find out what converts automatically, where the documented limits are, how long it takes, and what it costs in engineering effort.
Oracle®
Packages, exception handling, cursors and data dictionary views run natively on EDB Postgres AI (EDB PG AI). Five named customer migrations, including the FBI and the US Navy.
MySQL®
Schema and data convert with tooling. Views, triggers and stored procedures are the estimate. Target choice between community Postgres and EDB PG AI is a real decision.
Sybase/SAP® ASE
EDB PG AI Migration Toolkit officially supports ASE 15.7 and 16.0. Schema and data migrate with tooling; T-SQL procedures and triggers are rewritten. Planning ranges by downtime tolerance.
Greenplum
Binary-compatible swap for 7.x, with a two-step path for 6.x. No data movement, no schema change. Euronext FX cut over in hours, after months of planning.
On a MariaDB or Percona Server distribution? The MySQL page covers the same conversion surface—start there and tell us your distribution and version.
One methodology, whatever the source.
The same five stages, in the same order, wherever code and schema have to be converted. Greenplum is the exception—a binary-compatible swap skips the Transform and Move stages entirely.
Assess
Object inventory, complexity, application SQL
Transform
Schema and procedural code conversion
Remediate
The edge cases conversion leaves behind
Move
Coordinated transfer, reconciliation, sync
Validate
Integrity, correctness, performance under load
The first deliverable is a costed backlog, not a completed migration. Object counts, an application SQL classification, and the specific behavioral differences your estate will hit. That backlog is the project plan, and it is what an assessment produces, on every platform above.
The same four things on every platform page
Resources
Product
Information
Product
Information
Start with the estimate
An EDB migration architect works through your object inventory, application SQL, downtime tolerance, and target architecture. You come out with a costed backlog and a scoped timeline—which is what a budget conversation actually needs.