If your ERP or line-of-business system runs on Progress OpenEdge, you have probably heard that OpenEdge 11.7 is retired. Progress retired it on 1 April 2025 and directs remaining users to move to a supported release in the 12 series (Progress). That sentence tends to produce two reactions: panic ("the system is going to stop") or shrugging ("it still works"). Neither is quite right. This article explains what the lifecycle terms mean in practice and how to turn them into a plan.
The vocabulary
Progress publishes an OpenEdge product lifecycle document that describes the phases a release moves through (OpenEdge Product Lifecycle). The details are in the document itself and are worth reading for your own release, but the broad shape is:
- Long-term support (LTS) releases are the ones intended for production estates. They receive updates for an extended period.
- The active phase is when a release is current and receives fixes and updates.
- The sunset phase is a fixed window at the end of an LTS release's life. The lifecycle document sets that window at three years for the 11.7 and 12.2 LTS releases.
- Retirement is the end of that road. The release is no longer where fixes, security updates and support effort go.
The practical consequence of a fixed sunset window is that upgrades are not a one-off event. Whichever release you move to next will reach its own sunset in turn. An estate that treats the next upgrade as routine, with scripts, rehearsals and source control already in place, spends far less on the one after.
What retirement does not mean
Retirement does not switch anything off. A retired release keeps running exactly as it did the day before. Your licences, your database and your application are unaffected on the day itself.
It also does not mean that Progress is winding OpenEdge down. Progress continues to ship OpenEdge LTS releases and new tooling; the retirement of 11.7 is a step in the normal lifecycle, not a signal about the platform. Planning should be based on the release you are on, not on rumours about the product.
What retirement does mean
The risk of staying on a retired release grows slowly and then all at once:
- Security. New vulnerabilities in the release or its bundled components are no longer the focus of fixes.
- Operating systems and hardware. Each year it becomes harder to run an old release on a currently supported operating system, and older operating systems carry their own end-of-support dates.
- Integrations. Drivers, TLS versions and client libraries move on. Integration points that worked for years start failing in ways that are hard to diagnose.
- People. The people who know the old release well are retiring too. Hiring pages for Progress 4GL developers already describe ABL skills as scarce.
- The size of the jump. The further behind the estate falls, the larger the eventual upgrade, and the more of it has to be done under pressure.
Turning the lifecycle into a plan
A sensible plan has four parts.
1. Know where every environment is. Production, test, development, disaster recovery and any reporting copies can drift onto different releases and service packs. Write them down, along with the operating system each runs on.
2. Choose the target release. For most estates leaving OpenEdge 11, the target is a current LTS release in the 12 series. Check your ISV's supported-release list if you run a vendor application: their certification matters as much as Progress's lifecycle.
3. Size the work. The major items are the database conversion, the recompile of the ABL application, classic AppServer or WebSpeed to PASOE, client and deployment changes, and testing. Each estate weighs these differently. A database of a few gigabytes with a modern PASOE setup is a different job from a multi-terabyte database in Type I storage areas behind the classic AppServer.
4. Decide what rides along. An upgrade already pays for a full test cycle. That makes it the cheapest moment to move tables into Type II storage areas, clean up unused indexes, or put the source into Git. It is also tempting to add too much. Keep anything that changes application behaviour out of the upgrade unless it has to be there.
A note on timing
The best time to start is before anything forces your hand: before the operating system goes out of support, before the last developer who knows the build process leaves, before an auditor asks. Starting early lets you rehearse the database conversion several times on copies of production and schedule the cutover in a quiet week rather than the first available weekend.
Questions to answer this month
- Which OpenEdge release and service pack is each environment running?
- Can the application be recompiled from source today, from a clean checkout?
- Does the estate use the classic AppServer, WebSpeed or PASOE?
- How large is the database, and are its tables in Type I or Type II storage areas?
- When did someone last restore a backup to prove it works?
If any of those answers is "not sure", that is the first piece of work.
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.