by John Browne, on Oct 11, 2016 6:05:40 PM
Recently we announced the availability of a migration tool to move PowerBuilder apps to Java-based web apps. In a nutshell we migrate all the PB forms to HTML with Angular and Bootstrap for a nice responsive look&feel, hook up event handlers for all the controls, refactor the business logic into a Spring MVC pattern, and make it all work. Right now we have to run the tool for you (there's no product-level UI yet) but we've done this for a number of customer projects, some of which were very large.
The resulting app, like an app migrated from .NET to web using WebMAP, has readable code, modern patterns, relies on a lot of open source technologies, contains no dependencies on us or any other third party, and--most importantly--doesn't introduce defects into the existing business logic of the PB application. This not only reduces the risk of such a big transformation compared to, say, rewriting it from scratch, but reduces the overall cost and time to move the application forward.
Unlike VB6 PowerBuilder is still supported but like VB6 it's an archaic language/platform that is getting harder and harder to find developers that know it. Ask a 20-something BSCS grad about PowerBuilder and watch their eyes glaze over. It's like your Uncle Buck's 32" CRT TV in the basement it's super heavy, doesn't show college football in HD, and is getting hard to find parts for. But you have to watch it when you go there for Thanksgiving.
That doesn't change the fact that a lot of PB apps are still out there, chugging away. And some of those apps have large installed bases. And maybe you have an installed base that isn't ready to dump PB just yet. You can't always force customers to upgrade to a new version. Sometimes an app is so complex and integral to business processes that upgrading is risky and expensive. If it ain't broke, why fix it? And if they have support contracts and can't/won't switch you will have to continue to maintain that legacy version while creating a modern version to remain competitive.
You COULD just do the migration and hang on to your PB code. But now you have two (probably large) code bases (with different languages and architectures) to maintain. Ouch. Nobody in their right mind would want that set of problems and costs. You could stop maintaining the PB version and just focus on the web version but that might introduce a different set of issues.
Some companies have cross-platform solutions that rely on runtimes to solve this issue, but that means you have a dependency on a third party that might or might not make you comfortable.
What if you could keep the PB version as long as you want, update it as frequently as you want, and have the web version stay current without two sets of developers? What if you had a scenario like the following?
- You make changes to the PB code base
- You run a migration tool, which converts basically 100% of the PB code to Java-based web version
- You run your UAT suite and publish
- Rinse and repeat as needed.
What I'm talking about here doesn't require a code branch to complete the last mile. And it doesn't involve runtimes. It's all source code. The idea is "continuous migration:" an environment where you maintain one source code base while generating a new, completely migrated code base whenever you want. Compile both and publish. Instead of the disagreeable case where you basically double your dev and QA costs to maintain two separate code bases, you perhaps increase your costs by a factor of 1.1 or 1.2 and get the same product result.
This is not a hypothetical solution--it's real and we've implemented this for a very large application. It is NOT a single solution that works for everyone--there is a significant amount of app-specific customization in the tooling. And in some cases a few minor tweaks to the PB app were necessary to simplify the on-going continuous migrations. But the overall results were highly satisfactory and allows this particular organization to continue to support a large installed base of PB users who do not want to upgrade to a web version while at the same time offering a browser-based, modern web architected version to new customers.
If you have a similar situation, talk to us. We're seeing plenty of customers who are happy to wave "goodbye" to all their PB code, but some--like the example above--are in a tough bind and might be interested in a a novel solution. In that case, we can help.
