For many estates leaving OpenEdge 11, the database conversion is not the largest piece of work. The application server is. OpenEdge 12 runs ABL application services on the Progress Application Server for OpenEdge (PASOE), and the classic AppServer and WebSpeed brokers that many estates still depend on are not part of it. If your clients, web pages or integrations call a classic AppServer today, that has to change during the upgrade.
The good news is that most ABL business logic moves across with modest changes. The work is in the surroundings: configuration, session handling, connection strings, security and operations. This checklist is the one we work through on a conversion. Use it alongside the Progress documentation for your release.
1. Inventory what calls the AppServer
Before touching configuration, list every caller:
- GUI or character clients that connect to the AppServer;
- WebSpeed pages and the web servers in front of them;
- batch jobs and scripts that start AppServer requests;
- other systems calling in through Open Clients, SOAP or REST adapters;
- monitoring tools that query brokers.
For each caller, record the connection parameters, the operating mode of the broker it uses, and who owns the code at the other end. Callers you do not own, such as a partner's integration, set the pace of the cutover.
2. Understand your operating modes
Classic AppServer brokers ran in modes such as state-reset, state-aware, stateless and state-free, and the mode shapes how the ABL code treats sessions. PASOE has its own session model. Code written for a stateless or state-free broker usually moves most easily. Code that relies on a bound connection keeping its session context between requests needs the closest review, because that behaviour has to be reproduced deliberately on PASOE.
Search the code for anything that depends on session state between calls: shared or global variables, persistent procedures kept alive across requests, temp-tables populated in one call and read in the next.
3. Map broker configuration to PASOE instances
Each classic broker becomes an ABL application on a PASOE instance. Map, for each one:
- the PROPATH and startup procedures;
- database connections and their parameters;
- activate and deactivate procedures, which have equivalents in the PASOE session lifecycle;
- agent counts and pool sizing;
- logging levels and log file locations.
Resist copying every old setting across blindly. Some existed to work around problems that no longer apply, and PASOE's defaults are a reasonable starting point.
4. Move WebSpeed deliberately
WebSpeed applications can run on PASOE through its web transport. Check each page's dependencies on the old messenger and broker environment, such as CGI variables, cookie handling and file paths, and test them page by page. If a WebSpeed page is really an integration endpoint in disguise, this is a good moment to turn it into a proper REST service instead.
5. Decide on transports and security
PASOE exposes ABL logic over several transports: the APSV transport for Open Clients and ABL clients, REST, SOAP, and the web transport. Choose which ones each application needs and switch off the rest.
PASOE runs on a Tomcat-based web server, so security moves into its configuration: authentication, TLS, which URLs are exposed, and which users or services may call what. Write down the security model you intend before configuring it, and test that unauthenticated calls are actually refused.
6. Update the clients
Clients that connected to a classic broker now connect to a PASOE URL. Update connection strings, test timeouts and retry behaviour, and check that error handling copes with the new error messages. Where clients are installed on desktops, this becomes a deployment task with its own schedule.
7. Load test before cutover
PASOE handles concurrency differently from a pool of classic agents. Run the busiest realistic load you can produce against the new instance: month-end batch plus normal daytime traffic is a good target. Watch agent and session counts, memory, response times and database connections. Tune pool sizes based on what you see, not on the old broker's numbers.
8. Operations and monitoring
Operations teams need new runbooks: how to start and stop instances, where the logs are, how to tell a stuck session from a slow one, and how to deploy new r-code without restarting more than necessary. Point your monitoring at the new instances and retire the old broker checks.
9. Plan the cutover
Where possible, run PASOE alongside the classic AppServer in a test environment for a while before the upgrade, using a copy of the application, so the team becomes familiar with it before it matters. On the day, the cutover is mostly a change of connection targets, with the old configuration kept to hand for rollback until the new one has run a full business cycle.
After the move
Once the application runs on PASOE, the door is open to the modernization work many estates want anyway: exposing business logic as REST services to a web front end or a partner system, without screen-scraping or file drops. That is a separate decision, and it is easier made from a stable PASOE base.
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.