// Support takeover with no migration
Switch support vendors without migrating.
Keep your binaries, change your support.
Changing support vendors should not mean changing databases. OSSeva takes over support for the community binaries and the data you run today, starting with a planned transition and a 30-day onboarding. Once we know your estate, we ship our own patched builds on your schedule. Typical starting points are an EDB, Percona or Redis Enterprise contract coming up for renewal, or a team that has been supporting itself and wants backup.
Trusted globally by enterprises
Why teams stay with a vendor that no longer fits
The contract renews because changing it looks like a migration. It does not have to be one.
Switching sounds like a re-platform
Teams assume a new vendor means new packages, a new operator or a new distribution, and that is a project nobody has time for before the renewal date.
The knowledge sits with the old vendor
Runbooks, past tickets and the reasons behind configuration choices are spread across a portal you are about to lose. Without a handover plan, the first incident after the switch starts from zero.
Self-support works until it does not
Running community builds without a contract is a reasonable choice for many teams. The risk shows up in a 3am incident, or when an auditor asks who patches the version you run.
What OSSeva delivers
Transition plan
Before your current contract ends, we agree a start date, what we need access to and how open tickets move across. There is no overlap you do not choose.
Inventory, first 30 days
Every cluster, node, version, extension or plugin, and the tooling around it, recorded in one place you keep.
Version map, first 30 days
Each version mapped to its upstream end-of-life date and to the patched build OSSeva will ship for it.
CVE baseline, first 30 days
The known vulnerabilities in what you run today, ranked, with the fix or mitigation for each. This is the starting record for your auditors.
Runbooks, first 30 days
Failover, backup and restore, upgrade and incident runbooks, written or checked against how your clusters really run.
Patched builds on your schedule
After onboarding, signed OSSeva builds replace community binaries during your normal maintenance windows, with no data migration. On OSSeva Operate, Critical CVEs (CVSS ≥ 9.0) are patched within 48 hours and High within 7 days.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Renew your current vendor | Continuity and a team that already knows your estate | Right choice if you rely on features in their own distribution or tooling; otherwise the same contract and price model again. |
| Move to self-support | No support contract | Your team owns every incident, patch and audit question, including on end-of-life versions. |
| Re-platform onto a managed cloud service | Hosted operations | A real migration, on that provider's version calendar. |
| OSSeva support takeover | Support for the binaries and data you run today, then OSSeva patched builds | A 30-day onboarding while we learn your estate. |
OSSeva onboarding and tier details from the OSSeva technology pages, checked on 7 October 2026. EDB, Percona and Redis Enterprise are named only as common starting points; where a team depends on features specific to one of their products, staying may be the better fit.
Frequently asked questions
Do we have to migrate to switch to OSSeva?
No. OSSeva supports the community binaries and the data you run today. Our patched builds install like a minor release in your normal maintenance windows, on the same data.
What happens in the first 30 days?
We build an inventory of your clusters, a version map against upstream end-of-life dates, a CVE baseline of what you run today and a set of runbooks for failover, backup, restore and upgrades. You keep all of it.
We use EDB Postgres today. Can OSSeva take over?
If your clusters run community PostgreSQL, yes, and you keep your binaries and data. If you depend on features specific to EDB's own distribution, we will tell you what changes before you sign, and staying may be the better fit.
Can OSSeva replace Percona support?
For PostgreSQL, MySQL and MongoDB you run yourself, yes, with patched builds for versions upstream no longer supports. If you run Percona's own server builds, we confirm how we cover them before you sign. Where you rely on features specific to those builds, staying may be the better fit.
Is there an alternative to Redis Enterprise support?
For self-managed Redis OSS and Valkey, yes. OSSeva supports BSD-licensed Redis 6.2, 7.0 and 7.2 and Valkey 7.2 and 8.x. Teams that rely on Redis Enterprise-only features should weigh that before switching.
How is it priced?
Per cluster. Book a discovery call for a quote.
Who is this for?
Teams with a support renewal coming up who like the database they run and want a different support partner, and self-supported teams who need a contract for incidents and audits.
Keep your binaries. Change your support.
Book a discovery call before your renewal date and we will send a transition plan and a quote.