Migrating to PAS for OpenEdge: What “Best Practices” Really Mean
Migrating to Progress Application Server (PAS) for OpenEdge isn’t just a technical upgrade. It’s a shift in how OpenEdge applications are deployed, secured, scaled and operated.
That was the central takeaway from our recent webinar, “Progress Application Server (PAS) for OpenEdge Best Practices,” where Chad Thomson, Senior Principal Consultant at Progress, walked through what OpenEdge teams need to understand before, during and after a move from Classic AppServer or WebSpeed environments to PAS for OpenEdge.
From architectural differences and deployment planning to security, testing and performance tuning, the session emphasized one clear message: success with PAS for OpenEdge starts with setting the right expectations and being intentional from day one.
PAS for OpenEdge Is Not Classic AppServer—and That’s the Point
While PAS for OpenEdge replaces Classic AppServer and WebSpeed brokers, it operates very differently. PAS for OpenEdge is built on Apache Tomcat and communicates entirely over HTTP/HTTPS. That architectural shift introduces new considerations around request duration, concurrency, threading and network behavior.
Unlike classic environments where concurrency required multiple agents, PAS for OpenEdge uses multi‑threaded agents, allowing a single agent to service many concurrent ABL sessions. This enables greater scalability, but only when applications are designed and configured with that model in mind.
Treating PAS for OpenEdge as a “drop‑in replacement” without acknowledging these differences is one of the most common causes of migration challenges.
Start with Architecture and Deployment Planning
PAS for OpenEdge may look like a web server, but its role is closer to a broker replacement than a traditional UI tier. For most teams, that means starting where their classic AppServer brokers live today and working outward.
Key planning considerations include:
- Network paths and firewalls between clients and PAS for OpenEdge
- Required ports and transport protocols
- Existing broker definitions and client connection patterns
- Ancillary services and integrations that depend on AppServer or WebSpeed
A clear picture of the full application landscape, including external consumers and background processes, is critical to avoiding surprises later.
Configuration, Tooling, and Operational Differences Matter
Migration also means adopting new tools and processes.
Classic utilities like asbman, wtbman, and mergeprop do not apply in a PAS for OpenEdge world. Instead, teams must become comfortable with:
- PASMAN and TCMAN for instance management
- oeprop and secprop for configuration and security changes
- A broader set of configuration files, including openedge.properties and catalina.properties
Logging also changes significantly. In addition to ABL agent logs, teams must account for Tomcat logs, access logs, and Spring Security logs. Understanding where to look, and how much logging is appropriate for production versus troubleshooting, becomes a key operational skill.
Testing Is Not Optional—It’s the Strategy
Successful PAS for OpenEdge migrations require more than functional validation. Teams must:
- Stress test for concurrency
- Test realistic production workloads
- Test failure scenarios
- Validate behavior under load and during shutdowns
Defaults are rarely correct for real‑world applications. Only through testing can teams determine the right number of agents, sessions, and Tomcat threads for their specific workloads.
Just as importantly, Chad encouraged teams to target production early, using production‑like settings even in development environments, to avoid last‑minute surprises. And if you do test, test again.
Security Must Be a First‑Class Citizen
Security should not treated as an afterthought, it should be as foundational.
PAS for OpenEdge is secure by default, but teams must explicitly enable the transports and features they need. HTTPS is always available, and encryption in transit should be implemented early, not postponed until go‑live.
The session strongly recommended:
- Treating TLS/HTTPS as mandatory
- Leveraging Spring Security for authentication and authorization
- Integrating with enterprise identity providers such as LDAP, Active Directory, OAuth2, or OIDC
- Avoiding custom password handling in ABL code whenever possible
Reverse proxies were highlighted as a best practice for both security and flexibility, allowing organizations to protect PAS for OpenEdge instances while enabling URL rewriting, load balancing and routing.
Migration Is Also an Opportunity
Handled thoughtfully, the move to PAS for OpenEdge can result in:
- More scalable deployments
- Stronger security posture
- Better operational visibility
- Cleaner, more resilient application architectures
Final Takeaway
Migrating to PAS for OpenEdge is not just about getting off classic AppServer or WebSpeed, it’s about adopting a modern, scalable and secure runtime for OpenEdge applications.
Teams that succeed are the ones that plan deliberately, test relentlessly, embrace PAS for OpenEdge architectural model, and treat security and operations as core design considerations, not afterthoughts.
PAS for OpenEdge rewards preparation. And when approached with the right mindset, it becomes a foundation for the next phase of OpenEdge application growth.
Jessica (Malakian) Newton
Jessica (Malakian) Newton is a Senior Product Marketing Specialist at Progress, focused on the Progress OpenEdge product. Jessica started her career at Progress as an intern in 2020 and has since developed into a full-time marketer, dedicated to guiding customers on how to maximize the value of their OpenEdge solutions. Outside of work, Jessica enjoys reading and writing.
