Companies that have run Progress OpenEdge for more than fifteen years often face the same dilemma: the system works, supports daily revenue, and nobody wants to disturb it. At the same time, finding developers who know the platform becomes harder, and each new integration takes more effort.
A common response is to rewrite the whole system. It is also one of the riskiest.
Why a complete rewrite is so risky
A mature ERP built on Progress carries years of business rules that may exist only in its code. A tax calculation procedure, for example, can contain many conditions, each added after a real exception appeared in production.
A rewrite assumes the team can discover all those rules before development begins. In practice, some come to light only when the new system calculates a different number and the finance team notices. Developers then spend more time investigating the old system than building the new one, while the first useful delivery slips further away.
The challenge is the order of the work: the existing system needs to keep running while the team learns what it actually does.
Incremental replacement with the strangler fig pattern
The alternative is the strangler fig pattern: move specific capabilities out of the existing system one at a time, while the rest continues to operate. The old core becomes smaller as the new components prove themselves.
Progress OpenEdge offers established integration points for this approach. A practical sequence is:
- Expose existing capabilities. Make ABL procedures available as REST services through PAS for OpenEdge (PASOE). The business logic can stay in place while gaining a new interface.
- Move reads before writes. Reports and dashboards are useful early candidates. Because they do not change transactions, discrepancies can be investigated without altering operational data.
- Move writes after the rules are understood. Once the team has stable read paths and has documented the relevant behavior, transactional changes become easier to assess.
- Run both paths in parallel. During the transition, keep the existing system as the source of truth and compare the new results against it.
Parallel comparison helps reveal undocumented rules. It gives the team evidence about where the new implementation behaves differently before traffic or responsibility moves over.
The role of data
Progress systems often hold years of transaction history, but that history can be difficult to use for analysis. Heavy analytical queries may compete with the transactional workload for resources, limiting when reports can run.
Copying the relevant history to a separate analytical layer can protect the operational workload and make reporting more flexible. This can be an early deliverable that business leaders can evaluate while later stages of modernization are still in progress.
The same foundation can support use cases such as retail demand forecasting, where sales history alone is insufficient without stock availability and promotion data.
Treat the existing system as a source of knowledge
Calling every legacy system technical debt misses what it has accumulated. A system that has processed orders for twenty years may encode operational knowledge that a new specification does not yet capture. Replacing it without testing that knowledge creates avoidable risk.
Modernization should preserve proven behavior while changing what limits the business: difficult integrations, slow delivery, and dependence on a small group of specialists. That does not require discarding the entire core at once.
Where to start
Before choosing a technology stack, answer three questions:
- What is slowing the business down today? If changes take too long, the bottleneck may be in the delivery process rather than the programming language.
- Which rules exist only in code? Identifying them early helps establish the real scope of the work.
- What is the cost of a wrong result? Systems that move money need parallel execution and comparison before a cutover.
The answers often change the project scope more than a technology choice does.
If you maintain critical systems in Progress, Delphi, Java, or PHP and are evaluating a modernization path, talk to the Korvantis team. We work at the intersection of proven operational stability and current technology.