Of everything in an OpenEdge 11 to 12 upgrade, the database conversion gets the most attention, and rightly so. The conversion utility, proutil with the conv1112 qualifier, changes the database's on-disk format in place. Experienced OpenEdge DBAs warn that it carries a real risk of data loss if it is run carelessly or against a database that was not in the state everyone assumed.
The answer is not to fear the conversion. It is to rehearse it until the real run holds no surprises. This article describes how we approach those rehearsals. Always read the Progress documentation for your exact releases before running any of it: the prerequisites change between service packs.
Principle one: never convert the only copy
The conversion is run against a database you can afford to lose. In rehearsals that means a copy of production restored onto a test server. On cutover night it means production, but only after a full backup has been taken and restored somewhere else to prove it is good. A backup that has never been restored is a hope, not a backup.
Write down, before the first rehearsal, exactly how you would get back to the old release if the conversion failed halfway: which backup, which server, which release binaries, and how long it takes. That is the rollback plan, and the rehearsals are where it gets timed too.
Principle two: start from a known-good database
Many conversion problems are really problems that were already in the database. Before converting, check the source database's health on the old release:
- run the database and index checks your release provides, and investigate anything they report;
- make sure there are no users connected and the database was shut down cleanly;
- truncate the before-image file after a clean shutdown, as the documentation for your release describes;
- disable after-imaging and any replication for the duration, and plan how you will re-enable them afterwards;
- check free disk space against the size of the database plus generous headroom.
Each of these steps belongs in a script, not in someone's memory.
Principle three: time everything
The first rehearsal is mostly about discovering how long each step takes on your data and your hardware. Record the time for:
- the final backup on the old release;
- copying or restoring to the conversion server, if that is part of the plan;
- the conversion itself;
- any post-conversion steps your documentation calls for, such as index rebuilds or statistics updates;
- the post-conversion checks;
- a full backup on the new release;
- bringing up the application and running smoke tests.
Add those together, add contingency, and compare the total with the outage window the business can give you. If the numbers do not fit, you find out in a test lab instead of on a Sunday morning.
Principle four: check the result the same way every time
A rehearsal is only useful if you can tell whether it worked. Build a fixed set of checks and run it after every conversion:
- Record counts per table, captured before conversion and compared afterwards.
- Index checks on the converted database.
- Schema comparison: a dump of the data definitions before and after, compared with a diff tool.
- Application smoke tests: log in, look up a customer, enter an order, run a report, post a batch. Use the transactions that matter most to the business.
- A short performance comparison for a handful of known queries and batch jobs, against timings captured on the old release.
Keep the output of every run. When the final rehearsal looks exactly like the previous two, you are ready.
Principle five: the conversion is not the whole upgrade
The database format is one piece. The application also has to be recompiled against the new release, because r-code compiled under OpenEdge 11 is not what OpenEdge 12 runs. Classic AppServer or WebSpeed brokers need converting to PASOE. Clients need new installs or startup parameters. A good rehearsal exercises all of this together on a test server, with the converted database underneath, so the first time the whole stack runs on OpenEdge 12 is not cutover night.
When to restructure at the same time
If the database still holds tables and indexes in Type I storage areas, the upgrade is a natural moment to move them into Type II areas, typically by dumping and loading. That turns the conversion into a different job: instead of converting in place, you build a new OpenEdge 12 database with the structure you want and load the data into it. It takes longer, but it gives you a cleaner database and a natural fallback, because the old database is never modified. We cover that decision in Type II storage areas and dump and load.
The runbook
By the last rehearsal you should have a runbook that someone else on your team could follow: every command, every check, every expected timing, the point of no return, and the rollback steps. The person running cutover night should be reading it, not improvising.
Planning a move off a retired release? The OpenEdge Estate and Upgrade Readiness Assessment reviews your release position, database, AppServer topology and customizations, and ends in written findings, a conversion risk register and a sequenced plan. Tell us about your estate.