Nobody books a maintenance window expecting to use the rollback plan. The teams that come out clean are the ones that rehearsed both. Percona migrations run on that discipline: a representative test environment, a cutover proven there first, and a documented way back.
Three engagements below, depending on where you're starting: moving a database you already run, finding out what leaving Oracle, SQL Server, or DB2 for PostgreSQL actually takes, or getting your Galera cluster onto a distribution Percona builds, tests, and supports directly.
Migrations fail in the gap between the plan and the cutover, untested rollback procedures, missed replication lag, application changes nobody scoped, or a maintenance window that runs long because nobody tested the actual cutover steps beforehand.
This engagement covers MySQL, MariaDB, PostgreSQL, MongoDB, and Valkey/Redis migrations , on-prem, cloud, or DBaaS , and builds a fully tested target environment before cutover ever happens.
The actual scope depends on the source/target engines, data volume, and cutover complexity, and is refined during the planning phase. Applicable across MySQL, MariaDB, PostgreSQL, MongoDB, and Valkey/Redis, whether self-managed, cloud, or DBaaS.
A migration executed against a tested plan with a documented rollback path, not a maintenance window you're hoping goes smoothly. You'll know the cutover works before you schedule it, because we tested it in a representative environment first.
$26,000 starting from
MySQL, MariaDB, PostgreSQL, MongoDB, and Valkey/Redis migrations; on-prem, cloud, or DBaaS
A tested migration process, a documented rollback plan, and a scheduled cutover with off-hours support and emergency rollback assistance
2 days of monitoring, a follow-up health audit 2–4 weeks out, and a PDF findings report
The starting price covers the least complex environments; final scope depends on source and target engines, data volume, and cutover complexity, refined during planning
The Oracle or SQL Server renewal invoice, with its per-core licensing, RAC, and Enterprise Edition support, finally became harder to justify than the risk of moving off it. You started looking at PostgreSQL as an excellent open-source migration target.
Now comes the hard part, made easier by Percona. Nobody in your org has a clear picture of what's actually in the schema: PL/SQL or T-SQL procedures, custom data types, and the dependencies wired across it all. To make it worse, some applications don’t support PostgreSQL out of the box. Complexity assessment and related project risks - that's where most proprietary-to-PostgreSQL migrations stall and where a partner comes in. Today, up to 99% of manual conversion and migration efforts can be automated by purpose-built tooling. We’re proud to partner with HexaCluster to deliver this experience to you.
We start with a detailed assessment, delivered through a dedicated tool, to give you that picture in code-level detail before you commit to a migration timeline or budget. This proactive assessment adds the data component to the initial cost-based migration decision. It precisely tells you how long it will take to migrate a fleet of databases, and how much it will cost in software and expertise.
Built for teams running Oracle, Microsoft SQL Server, or IBM DB2 who are evaluating a move to PostgreSQL to get out from under proprietary licensing costs. The default path is native PostgreSQL; rewriting PL/SQL or T-SQL logic into standard, fully open source PostgreSQL, no compatibility layer required. Where the assessment turns up heavy stored-procedure or proprietary-type dependency and a full rewrite isn't realistic on your timeline, you’ll have the option to add HexaCluster's HexaBridge compatibility layer as a way to fast-track cutover without rewriting the application. This is an assessment engagement; cutover and the full migration build are scoped separately based on what the assessment finds.
A concrete, code-level answer to how hard this migration actually is, before you've committed a budget or a timeline to leadership. You'll know which parts of your schema convert cleanly and which parts need real engineering effort, so the migration proposal that follows is based on your actual environment, not a vendor's average case.
$5,000 starting from
Oracle, Microsoft SQL Server, or IBM DB2 environments evaluating a move to PostgreSQL
A DMAT assessment with compatibility scoring, effort estimation by schema object type, and a migration path recommendation, plus a findings rundown with your team
Native, fully open source PostgreSQL by default; a compatibility layer is available where DMAT finds heavy stored-procedure dependency
This is an assessment engagement; cutover and the full migration build are scoped separately based on what DMAT finds
MariaDB acquired Codership - the original creators of Galera Cluster in May 2025. This lead to two important changes for MySQL Galera Cluster users: In February 2026, MariaDB moved to strip Galera clustering libraries from the community server entirely, then reversed course after public pushback, including from its own foundation, and confirmed that Community Server 12.3 will keep Galera. Regardless of this development, at the end of September 2026 MySQL Galera Cluster goes EOL and won’t be further developed which means its users are forced to implement changes.
If your production HA strategy depends on a library MariaDB has already tried to pull once or you run the original, MySQL version of it, that's not a hypothetical risk; it's a live one. This engagement migrates your cluster to a Galera-based architecture (Percona XtraDB Cluster) that Percona builds, tests, and supports directly, so your HA strategy isn't tied to MariaDB's next roadmap decision.
Built for teams running MySQL or MariaDB Galera Cluster in production who want reliable and future proof HA strategy. Actual scope refined during planning based on cluster size, used features, and application dependencies.
A Galera-based cluster running on a distribution Percona builds, tests, and supports directly, so future MariaDB decisions don’t become your outage. You keep the multi-master architecture your application was built around; you stop depending on another vendor's willingness to keep shipping it for free.
$26,000 starting from
Production MariaDB Galera clusters moving to Percona XtraDB Cluster or another Percona-supported HA architecture
A tested migration process, a documented rollback plan, and a scheduled cutover with off-hours support and emergency rollback assistance
2 days of monitoring, a follow-up health audit 2–4 weeks out, and a PDF findings report
Refined during planning based on cluster size and application dependencies
FAQ’s
