Upgrading to OpenEdge 12.8 isn’t just a checkbox on your roadmap—it’s a one‑way trip that can quietly corrupt your database if you miss one critical step. The official docs tell you to run proutil db -C conv1112 and move on, but they don’t shout loud enough about the data‑loss bug hiding in that very command. In this post, I’ll walk you through the real‑world risk, why a “good enough” backup isn’t good enough, and how to upgrade your OpenEdge 12 database without gambling your data.
Why you should care about OpenEdge 12.8
Beyond the obvious end‑of‑support cliff for 11.7, OpenEdge 12.8 brings real performance and security improvements that matter in production. Newer releases tighten encryption handling, improve query‑plan stability, and reduce the risk of certain classes of bugs. If you’re still on 11.7, you’re not just running an unsupported version—you’re running a slower, less secure, and less predictable one.
Progress has also extended long‑term support for 12.8, which means you’ll get security patches and bug fixes for years to come. That’s a big deal if you’re running mission‑critical applications on OpenEdge.
Now is the time to upgrade to OpenEdge 12.8
If you haven’t already upgraded to OpenEdge 12.8, now is the time to plan and execute your upgrade. OpenEdge 11.7 will reach retired status on April 1, 2025. After that date, 11.7 will receive no more security or bug fixes, and Progress will provide a reduced level of support. See the following links for more details:
When you are upgrading OpenEdge across a major‑version boundary, e.g. from 11.x to 12.x, at a minimum you are required to upgrade the database, using the Progress conversion utility. Example:
proutil <dbname> -C conv1112
OpenEdge Release 12.8.3 as of Thu May 30 13:50:05 EDT 2024
You must have your database backed up before running the conversion. (1024)
Have you done this (y/n) ? y
Important: the utility prompts you to back up the database before conversion, but it does not require you to do so. You should always perform a backup prior to running the conversion.
If your database size and downtime window do not permit you to back up via probkup, then back up your database offline by some other valid means, e.g. an OS copy. Be sure that your structure file is up to date (via prostrct list <dbname>) to ensure that you copy every single database file.
If you make a backup copy of your database by some means other than probkup, be sure to open that database copy to prove to yourself that it works.
Before you run conv1112: a checklist
Before you run conv1112, do this:
-
Verify your database is in a clean state (no open transactions, no pending backups).
-
Confirm that your structure file is up to date (prostrct list <dbname>).
-
Decide how you’ll back up (probkup vs. OS copy) and prove the backup works.
-
Check for TDE‑related objects and null‑cipher‑enabled objects if you’re using encryption.
-
Plan your downtime window and communicate it to the business.
This isn’t just “best practice”—it’s the difference between a smooth upgrade and a late‑night emergency.
The data‑loss bug in proutil conv1112
Progress recently published a knowledgebase article about a bug in the proutil conv1112 conversion utility. See these links for the details:
These are the circumstances that lead to the bug:
-
OpenEdge TDE is installed and the database is encryption‑enabled;
-
An object has an encryption policy with the null cipher;
-
The user runs the upgrade utility.
A potential result is a corrupted, unusable database. Note the resolution given in the knowledge base article: “restore from backup”. If you didn’t take a backup before continuing with your conversion, you could lose data permanently!
Be sure to read the linked articles for the full details and workaround.
The important lesson
Even if you don’t use OpenEdge TDE and thus you are not affected by this particular bug, it illustrates a very important general point: the OpenEdge conversion utility makes changes to your database, and they are irreversible. It is software, and software can contain bugs, including critical data‑loss bugs.
Be sure that you always back up your database, and test that backup, prior to running the database conversion.
What if something goes wrong?
If conv1112 fails or leaves your database corrupted, your only real option is to restore from backup. That’s why testing the backup is non‑negotiable. If you don’t have a working backup, you’re essentially gambling your data on the assumption that the utility will behave perfectly. In my experience, that’s not a bet worth taking.
If you do run into issues, Progress support can help you troubleshoot, but they’ll likely tell you the same thing: restore from backup and try again with a cleaner environment.
Subscribe to PANS!
How did White Star know about this issue, and other happenings in the world of OpenEdge? We subscribe to PANS, the Progress Alert and Notification Service.
Subscribe here with your free Progress ID:
https://community.progress.com/s/pans
Every technologist working with OpenEdge should subscribe to PANS. It is a must. Once you subscribe, you will receive a daily e‑mail summary with links to new and updated knowledgebase articles about the Progress products you select. You will also be notified when Progress ships updates for long‑term support (LTS) OpenEdge releases, and when there are critical vulnerabilities found in the product.
How we use PANS at ProTop
We treat PANS as our early‑warning system for OpenEdge. Every day, we get a digest of new and updated knowledgebase articles, LTS updates, and critical vulnerabilities. If there’s a bug in a utility we use (like conv1112), we hear about it before it hits our customers. If you’re not on PANS, you’re effectively flying blind.
What’s next after the upgrade?
Once you’ve upgraded to 12.8, don’t just walk away. Monitor your database for any performance regressions, check your backup strategy, and validate that your applications still behave as expected. If you’re using ProTop, this is a great time to baseline your performance and catch any issues before they become incidents.
You should also review your encryption policies, especially if you’re using TDE, and make sure they’re aligned with the latest best practices. A clean upgrade is only half the battle—keeping the environment stable and secure is the other half.
Conclusion
Done right, upgrading to OpenEdge 12.8 is a straightforward, low‑risk operation. Done wrong, it can leave you with a corrupted, unusable database and no way to roll back. The key is simple: always back up your database, always test that backup, and always assume that any irreversible utility can contain bugs. If you follow those rules, you’ll upgrade with confidence instead of crossing your fingers.
If you’ve already upgraded to 12.8, I’d love to hear how it went—especially if you ran into any surprises. Let’s talk about it in the comments.
Comments