PowerBuilder was for years considered one of the best application development software solutions among Rapid Application Development (RAD) software technologies. Its main benefits were speed and simplicity, which are primarily provided by its DataWindow component and IDE. Unfortunately though, due to advances in technology and programming languages as well as business needs, PowerBuilder is falling into obscurity. The results of this decline are diminished support services as PowerBuilder experts are becoming scarce, and there is a lack of extensibility for PowerBuilder-based applications. Many firms have migrated from PowerBuilder to modern platforms such as Java and Microsoft .NET platforms. Legacy migrations such as PowerBuilder to Java have their benefits, along with some issues to watch out for.

The main benefit gained from the PowerBuilder to Java migration is platform flexibility. Other advantages associated with this migration are both platforms can achieve the same type of look and feel and PowerBuilder to Java can be accomplished with some degree of automation. Both platforms support compatible error handling and security as well as near exact replication. As an upgrade, the PowerBuilder to Java migration provides similar services as the PowerBuilder Classic version, just with more efficient technology. As such, the PowerBuilder to Java upgrade can deliver the same or better productivity levels in a modern environment; little to no limitations on the target server platform; as well as an open, flexible platform development environment. This means the upgrade should enable application design and creation using the latest software development methods. Maintenance costs will also be reduced.

As with any legacy system migration, an investment in money and expertise is needed. One of the key decisions to be made is whether a line by line translation of the Powerbuilder makes sense, or whether an approach closer to native .NET or Java is better. There are companies who do a good line by line translation, but the result is not what modern programmers are used to seeing when applications are written “from scratch”. And, there will be proprietary vendor dependencies, such as for whatever new control and API is used for DataWindow functionality. In contrast, our approach is an automation-assisted rewrite of the application, which takes a little more effort than a line by line translation but yields all the benefits of a custom rewrite — without the risks.

Here are a few considerations that organizations may want to take into account when considering which vendor to employ for their PowerBuilder to Java migration. PowerBuilder to Java migration companies should have:

1. High quality expertise and successful track record – The vendor should have a team of capable experts as well as practical experience in legacy software migration. It’s an added benefit if they have successful previous experience in PowerBuilder to Java migrations and support the latest versions of the modern Java and .NET platforms.
2. Cost-effective and rapid delivery – As a PowerBuilder to Java migration is taking place, the organization must remain operational. Thus the migration should take as little time as possible to avoid disruption of business. It’s even better if no code freeze is required during modernization.
3. A customer-centric approach and skilled IT resources – Every stage of thePowerBuilder to Java migration project should have clearly designed goals whose overall aim is to fulfil the current needs of the organization.

While maintaining the PowerBuilder platform is perfectly feasible for now, staying in PowerBuilder does widen the gap between the businesses IT shop and other advances in technology. The main reason for migrations such as PowerBuilder to Java is so that organizations can profit from the rapid and dynamic changes in frameworks and programming languages, while being able to recruit from a much bigger pool of programmers and avoiding once and for all those costly desktop deployments and licensing.