PowerBuilder Applications are still the backbone of important international business, where the substance is more important than the appearance. There are several migration paths to upgrade a PB application, but the main concept is: do we need to trash our PB applications and their valuable business power just because their UI is obsolete?

Maintaining an application provides a critical lifeline for the tool that supports and backs up our business needs. Pretty much like maintaining a powerful car or even an aircraft – you cannot leave the tool without maintenance and expect proper functioning.

So first of all, we need to be able to maintain our applications: upgrading to the latest PB version, support for the latest DB and OS versions, being up to date with security best practices. Small modifications (reporting, simplification, …) keep the applications usable.

 

Then another range of small changes is worth considering: upgrading the application with more modern tools and components. The PowerBuilder ecosystem is quite rich and you can find tools (part of PB or 3rd party) for: modernizing the UI, localizing the application, create beautiful reports and dashboard, hosting Web pages interacting with the application, sending SMS/WhatsApp and mass emails, securing the application, using ribbons and docking component, deploying a self-updating application, deploying a desktop-cloud application, relying on external APIs, creating an application navigator, exposing the business logic as Web API, and much much more.

 

I’ve been asked so many times to inspect an application and suggest a path for modernizing it. Some of my customers have done it by themselves. Some of them have asked for supervision of the activity while implementing the changes. Some of them completely outsourced the upgrade. But the point here is that modernizing a PowerBuilder application is more than possible, even when you plan a complete rewrite.

 

In fact, PowerBuilder is notorious for making hard a “rewrite from scratch” approach. Why so?

  • The richness of the PowerScript 4GL, and most important the datawindow and the datastore
  • The productivity of the IDE that allowed to create gigabytes of source code in short time
  • The data-centric orientation, where writing complex business logic and transactions is not the activity of a senior backend developer

 

Due to these advantages, we all have created in the past 20 years monster applications that:

  • Dance with business logic, solving complex problems and implementing sophisticated, flexible, rich business logic, that developers can still maintain after so many years
  • Have UI and business logic tangled together
  • Only run on a PC (even though in the early days PB was cross-platform…), with a non-browser UI, showing the sign of the time
  • Are effective and business strong
  • Are very difficult to rewrite from scratch

 

There are several migration approaches, including extracting the business logic (the strongest part of the applications) and creating a new UI, a modern one. Of course creating a new business logic, with new fashionable approaches, with new paradigms, is very attractive. But companies need solutions in the short/mid term, not beautiful creative and untouchable pieces of art, forever in development. Look at the microservice fashion that soon turned to modular monoliths. Fashion is surely cool, but in many cases it is very short lived. How many cases have I witnessed where during a huge porting the base technology evolved several times, forcing developers to re-architect and rewrite the implemented solution…

 

So, with my experience, I have found companies implementing the following approaches:

  • Abandon the PB application (no maintenance at all), and endanger significantly their business
  • Abandon the PB application maintenance, build (for many many years) a new application – hopefully effective and not just beautiful
  • Keep the application updated, while creating a new application or migrating it
  • Modernize the application, while creating a new application or migrating it

 

I have maintained, modernized, migrated together with my team several successful applications, always reusing something. In the end, it is better to change a car when the old one is not falling apart!