Percona and HexaCluster have partnered to remove the hardest part of an open source database migration: getting off Oracle, SQL Server, DB2 or Sybase ASE with confidence, on a predictable timeline, without a multi-year consulting program. Percona brings open source expertise, its own distributions, operators and enterprise support. HexaCluster brings the assessment and migration engineering that gets workloads onto those supported databases.
In this Q&A, Avi Vallarapu, CEO of HexaCluster, explains what the partnership changes for organizations planning an Oracle migration, why a database migration assessment is the single most valuable step, and how a joint engagement runs from first assessment through long-term support.
Percona and HexaCluster is a joint database migration partnership that moves organizations off Oracle, SQL Server, DB2 and Sybase ASE onto Percona-supported open source databases, primarily PostgreSQL. HexaCluster runs the assessment and migration engineering, using its own DMAT and HexaRocket tooling. Percona runs the resulting database long term through its distributions, operators and support.
Short version: HexaCluster gets you to open source. Percona keeps you running on it. Together, that’s one path from a proprietary database to a fully supported open source one.
Avi: HexaCluster comes from the same place Percona does. We’re open source contributors first. Our team has contributed to more than 50 popular PostgreSQL extensions, and over 90 percent of what we build is open source.
The best known example is Ora2Pg, the most widely used open source Oracle-to-PostgreSQL migration tool, created and maintained by our team. Google Cloud, Microsoft Azure and AWS have all pointed customers to it for complex schema conversions. We’ve also built extensions that emulate Oracle and SQL Server behavior inside PostgreSQL, making application code portable instead of rewritten.
That work taught us where migrations actually break, which is where HexaRocket came from. Almost every existing migration tool is partial: some handle schema conversion, some handle data migration and change data capture, very few do both, and almost none give a credible rollback. Customers end up stitching disconnected tools together, and the seams between them are exactly where migrations fail.
HexaRocket runs the whole path in one platform: schema migration with validation, data migration with validation, change data capture for live replication, and reverse replication so you can roll back if something goes wrong. Rollback is what lets a CIO approve a cutover date.
Avi: Because neither company covers the whole journey alone. Percona is the master of open source on the services and product side: Percona Distribution for PostgreSQL, Percona MySQL, Percona Software for MongoDB, the Percona Operators, and enterprise support. That’s hard to replicate.
What Percona hasn’t done is move workloads off Oracle, SQL Server, DB2 or Sybase in the first place. That’s the gap HexaCluster bridges.
Put simply: HexaCluster gets you to open source, Percona keeps you running on it. That’s the whole journey covered by two open source companies, not a general-purpose systems integrator learning your database on your budget. It works in reverse for us too: when customers ask what they’re landing on, pointing at Percona’s distribution, with built-in transparent data encryption, makes that conversation simpler.
Avi: It’s not new. I joined Percona in 2018 to start and lead the PostgreSQL practice there. The relationship continued through everything I’ve built since, first through MigOps and now through HexaCluster. This partnership formalizes a working relationship that’s existed for years.
Avi: Three things, stacking on top of each other.
Cost optimization. Commercial database licensing is one of the largest and least defensible line items in most infrastructure budgets. When finance looks for structural savings, this is where they land.
Scale in the AI era. Organizations are scaling data volumes faster than planned. Per-core commercial licensing turns growth into a penalty; open source turns it into a hardware conversation instead of a procurement one.
Features and performance. PostgreSQL isn’t the pragmatic compromise anymore. It’s the target: extensions, JSON, logical replication, partitioning, and now transparent data encryption through Percona’s work on the Distribution. The question has shifted from whether to adopt PostgreSQL to how fast the rest of the estate can follow.
Avi: They skip the assessment.
Migrations fail long before cutover, at the point someone estimates the effort without knowing what’s actually inside the databases. Some carry genuine complexity: heavy PL/SQL, embedded business logic, dependencies nobody has read in a decade. Others are almost trivial. Without an assessment, you can’t tell those apart, so both estimates are wrong.
Two mistakes compound that one: choosing a partner who treats your migration as a learning exercise, and choosing disconnected tools that leave the integration risk with you. Assessment first. Everything else gets easier after that.
Avi: It’s one team across the full lifecycle. The engagement starts the moment someone first thinks about migrating: assessment, then roadmap and sequencing, then schema and data migration with validation at every stage, then cutover with rollback available, then production, then support for as long as the database lives.
The customer isn’t managing a handoff between an assessment vendor, a tooling vendor, a migration integrator and a support provider. That’s where cost, delay and blame usually live. The result is cost-effective and easier, because the people who build the tools are the same people who support the databases afterward.
Avi: Two examples.
A leading Middle East bank had a very large Oracle footprint. We assessed 120 Oracle databases in 30 minutes, then handed them a complete migration roadmap within two days. Individual databases ranged from 30 minutes to four days of work to them out of Oracle each, roughly 40 person-days across the whole estate. We also ran a proof of concept in two days and showed a working migration, not just a demo.
A global enterprise moved 800 TB of databases from Oracle Standard Edition to Amazon Aurora PostgreSQL, covering more than 6,000 customers, as part of an acquisition strategy, completed over two years with validation and direct customer coordination throughout.
Both examples share the same pattern: unknowns get resolved at the start, not discovered in the middle.
Avi: The most valuable thing is that the customer doesn’t have to invent migration from scratch. It’s a solved problem they can buy: no unknowns, because the assessment tells you what’s in the estate before you commit to a plan; validation at every stage, so schema and data are verified, not assumed; rollback through reverse replication, which is what makes teams willing to schedule a cutover; and committed timelines, which is often the real blocker for leadership.
Avi: Three questions, in this order.
Did I pick the right database to migrate first? Starting with the hardest one is the most common self-inflicted wound. It burns budget and demoralizes leadership before any value is delivered.
Have we actually assessed our databases, so we know which ones are low-hanging fruit and which need real engineering? Without that, you’re guessing.
Did we pick the right tooling: a platform genuinely built for end-to-end migration, not a set of disconnected tools stitched together? Get those three right, and the migration is largely an execution problem.
Avi: Four exits dominate the conversations we’re in: Oracle, SQL Server, DB2 and Sybase ASE. Sybase ASE deserves a special mention, since customers there are being pushed toward SAP or SQL Server, trading one proprietary database for another. Through this partnership, PostgreSQL becomes a realistic, cheaper target instead.
Many of these tie into data center exits and hybrid cloud programs, where a single platform pays off most. We cover homogeneous migrations (PostgreSQL to PostgreSQL, MySQL to MySQL, any platform to any platform), heterogeneous migrations (Oracle, SQL Server, DB2 and Sybase ASE to PostgreSQL), and same-engine platform moves, like Azure Managed SQL to SQL Server on VMs. A data center exit is rarely one type of migration. It’s usually all three at once, under a deadline set by a lease or a contract.
Avi: Start with the assessment. It’s fast, it’s concrete, and it’s the step that de-risks everything after it.
We invite organizations to run a DMAT database migration assessment across their estate and get back a detailed roadmap: which databases to move first, what effort each one takes, and what the cost savings look like. From there, Percona and HexaCluster can take it through to production and support it long term.
You don’t need to commit to a migration to find out what one would cost you. That’s the point of assessing first.
To start an assessment or discuss an Oracle, SQL Server, DB2 or Sybase ASE exit, contact your Percona representative or reach out to HexaCluster directly.
Resources
RELATED POSTS
