Does anyone out there have any experience porting a large Powerbuilder client/server application to a Java application (or another language)? By large I mean something on the order of 2 million lines of code and literally hundreds of database tables. How did you do it? How long did it take and how much did it cost? What were the biggest challenges?

3 Answers 3


No experience in moving Powerbuilder code, but I have worked in a few significant in size and complexity porting projects.

First, I would consider evaluating some full featured mature round trip engineering tools, like IBM/Rational Rose, with appropriate plugins (for instance, Rose PowerBuilder Link by Metex) to read as much of the Powerbuilder/Powerscript/DataWindows/PBNI as you can, and build a semi-neutral model. Tune the model, and then generate your code skelaton in the appropriate implementation language. If you have test scripts, even if not automated, obtain those, and implemenet as much of them as possible in the target implementation platform's unit and acceptance testing frameworks. Finally, the heavy hand work.

Cost of any porting project when changing platforms or paradigm is going to be high. You'll need people with expertise on both ends of the port. You'll need someone who can talk or translate between the two and/or build/tune/operate the translation tools. You are reinventing the wheel, so your advantage is you know how it should end up, such that it doesn't have to do anything more or anything less; however, some things will simply not translate.

Will the underlying client platform and database be rehosted too? Or will that for the time being, remain as presumably a Windows client and Sybase database server respectively; or will those need to be reingeered also?

Edit: mention of any product is not an explicit endorsement, and I am not affiliated in any way with the products. However, I have used Rose extensively years ago, and found it largely effective, but I can not speak to recent incarnations.

  • Thanks for the info. I hadn't thought of that approach. I'd love to re-engineer the data model for sure but I was thinking we'd leave that for the time being. I understand now why there is so much legacy code out there now. It is extremely expensive and time consuming without immediate pay back to port a mature product to a new platform. Thanks again for the info. Mar 2, 2011 at 1:51

A friend of mine who changed his focus from PowerBuilder to Java (switching back whenever the occasion called for it) said the real kicker was the DataWindow. At the time, there just wasn't anything that had all the features: scollable, nestable, WYSIWYG printable (not trivial in Java), binding 1-to-n, attributes (graphical and behvioural) controlled by data-bound expressions or scripts, providing pre-implemented functionality like SQL injection protection, built in logical record locking, null argument handling, minimal SQL creation, DBMS portability, various methods to handle memory for data (e.g. Rows To Disk, Retrieve As Needed), ability to monitor, intercept, modify and cancel SQL at run time, etc........ No doubt there are alternate technologies are making progress, but in his opinion, nothing fully covered the functionality requirements of replacing the DataWindow.

As far as cost goes, it could be anything. There's one case (I've heard second-hand) of a company that spent (IIRC) $75M, and in the end gave up and returned to PowerBuilder. That's not to say your app is impossible to convert, but depending on how sophisticated and advanced your use of PowerBuilder, it could be a major effort. Think rewrite costs; that's really what you're doing. Sorry, but the word "porting" runs the risk of self-delusion, not that there aren't vendors out there pushing the delusion.

Good luck,



10+ years ago we started a transition from Powerbuilder to Tomcat. Have no idea of the LOC, we had approx 600 tables. It was a transition from Windows UI to a web UI and we did it with a small team over 2-3 years. The Powerbuilder code and Java code interacted with the same backend database during the transition. Was a great day when we could decommission the Windows client and be done with it.

The product was not transaction intensive, just lots and lots of screens to be converted into web pages. Do you use the DW for displays, updating data, on-screen sorting? Nowadays there are lots of jquery or Google web toolkit things for easy UI tricks.

Would recommend Struts, hibernate, spring or any other MVC tool. In Java we built an API layer that talked to the database, and then a UI layer that talked with the JSPs. You want to corral your database connections into one set of objects rather than opening/closing db connections all over the code.

Your solution depends on the requirements of your product/application and whether it is going to be a desktop app or a web based app. We went web-based and the deployment is a lot easier. Good luck.

Not the answer you're looking for? Browse other questions tagged or ask your own question.