Can our data even get out, and in what shape?
Every exit rests on one question that's easy to skip until it's too late: can you extract your data in a format something else can read? Pick a product and this checker tells you how cleanly the data comes out, in what formats, by what mechanism, and, most importantly, what stays behind. That last part, the history, credentials, and proprietary logic that don't travel, is usually the real constraint.
The data can leave, but meaningful pieces stay behind and shape the migration.
- Export formats
- Data Pump (.dmp), CSV, and SQL via ora2pg to PostgreSQL
- How you get it out
- expdp/Data Pump for like-for-like; ora2pg to convert schema, data, and much PL/SQL to PostgreSQL.
- What stays behind
- PL/SQL packages, proprietary features (RAC, partitioning options), and app SQL that assumes Oracle dialect, the long pole is code, not data.
- Your escape hatch
- Run ora2pg's assessment report to quantify the PL/SQL surface before scoping; the data moves cleanly, the logic is the work.
General, commonly-reported characteristics based on the OffVendor Lock-in Index, not a statement about any specific contract or the current version of any product. Confirm export capabilities against the vendor's own documentation and your deployment before you rely on them.
Why "can I export?" is the wrong question
Almost every vendor can technically export something. The question that decides whether an exit is real is what comes out and what doesn't. A database exports its rows cleanly but leaves behind the stored procedures your application depends on. An identity provider exports user profiles but not password hashes, forcing a re-enrollment wave. A backup product restores data to open form but keeps historical restore points readable only by itself, so retention obligations keep it installed for years. The data leaving is table stakes; the value that stays behind is the lock-in.
This tool makes that distinction explicit for every product it covers, pairing the export mechanism with the "stays behind" reality and a practical first move to reclaim portability. It's built on the data-portability dimension of the Lock-in Index, our original research scoring how hard 60+ products are to leave.
Turn a verdict into a plan
Use the checker before you sign and before you commit to an exit. If the data exports cleanly, your migration risk sits in the surrounding logic, scope that separately. If it's partial or hard, the escape hatch tells you where to start: prove the export early, plan a coexistence period, or budget a re-enrollment. From there, score your overall preparedness with the Exit Readiness Score, cost a cloud data move with the Egress Estimator, and, when the renewal lands, make sure a data-return guarantee is in the contract with the Renewal Redline.
Frequently asked
What does 'data portability' actually mean here?
Whether you can extract YOUR data from a product in a format something else can read, and how much of the surrounding value (history, config, credentials, proprietary logic) comes with it. It's the precondition for any exit: if the data can't leave, nothing else matters.
Where do the verdicts come from?
Detailed records for 21 high-interest products describe the export format, mechanism, and what stays behind. Every other product in the Lock-in Index (72 total) gets a verdict derived from its data-portability score, so you always get an answer.
Is this specific to my contract or version?
No. These are general, commonly-reported characteristics, not a statement about your agreement or a particular release. Always confirm export capabilities against the vendor's own documentation and your deployment.
What should I do before signing a new vendor?
Confirm the export path exists and is documented, ideally test it in a trial, and get a data-return guarantee into the contract. The Renewal Redline flags when that guarantee is missing.