ABL Modernization

A rewrite is usually the most expensive and riskiest thing you can do to an application that runs the business. ABL modernization is the alternative: improve the system in place, module by module, while it stays in production and keeps earning its keep. If you later decide to replace it, the work still pays off, because the business logic ends up documented, tested and reachable through clean interfaces.

What modernization can include

• ABL business logic as REST services. Expose existing procedures and classes through PASOE so web front ends, partner systems and integration tools can call them without screen-scraping or file drops.
• Screen replacement, a module at a time. Character (CHUI) and fat-client screens replaced by a modern front end over those services, starting with the screens your users spend the most time in.
• Object-oriented refactoring where it matters. OOABL refactoring of the most tightly coupled procedural code, so changes stop rippling across the system. Code that works and nobody touches can stay as it is.
• Characterization tests. Tests that record what critical logic does today, written before anything is changed, so a refactor can be checked rather than trusted.
• Source control and CI for ABL. Source in Git, compiles from a clean checkout, and automated builds that produce the r-code you deploy. See ABL in Git and CI.
• Reporting and warehouse feeds. Getting data out of the OpenEdge database into the reporting or warehouse tools the business already uses, without loading the production database at month end.

How we scope it

Modernization is planned module by module. Each step is small enough to ship and roll back on its own, and each one is chosen because it removes a specific cost: a slow screen, a fragile integration, a change that takes a week when it should take a day. There is no big-bang cutover.

Engagements are hourly, by senior US engineers, as a project or alongside your own developer.