Migrating PowerBuilder applications to new technology platforms can be daunting and there is an abundance of information available from many different sources, including vendor documentation, migration service offerings, technical articles and community forums.
If you're seeking guidance from people who have expertise and experience that you can count on, you will find the best resources collected in this guide.
This guide provides access to all of the official documentation, specialist migration guides and useful articles detailing various options for migrating applications, the largest challenges associated with those types of migrations, and the best methodologies for continuing to use PowerBuilder applications post-migration.
Best expert guides to read first
1. Medium: What Options Are Available for Migrating My PowerBuilder Applications to Newer Technologies?
The decision guide provides five paths to follow: upgrade & stabilize, automate your migration to .NET, extract services, automate your migration to Java or replace/rewriting.
It also identifies common pitfalls (such as trying to rewrite everything at once, forgetting about DataWindow’s custom business logic, & assuming web based applications will be easy to deploy) that typically cause a project to fail.
2. Kumaran Systems: Java vs .NET for PowerBuilder migration
If your main issue isn't deciding whether or not to move, but where to go, read on. Kumaran points out that Java is appealing to companies looking to standardize their enterprise applications across platforms due to its portability.
On the other hand, companies using .NET would typically choose to migrate to it if they align themselves with Microsoft products and want a large pool of developers available to work on the application after migration.
The example used to illustrate this is the difficulty in mapping DataWindow controls, reports, and event models when migrating from PowerBuilder / Sybase to Java.
3. Mobilize.Net WebMAP documentation
For those considering automating their migration out of PowerBuilder (to a more current web stack) this document provides valuable references.
The documentation provides clear instructions on migrating from PowerBuilder to either .NET or Java. The document also includes information on all aspects of the migration, including conversion processes, post-conversion tasks, and troubleshooting information.
This is particularly valuable to someone who is undertaking a serious migration, as typically a migration starts with converting the code and does not end until c# and java code is delivered to the environment.
Official guides you should not skip
4) Appeon: migrate to PowerBuilder 2025
The purpose of this document is to provide an overview of the supported upgrade paths.
According to Appeon, PowerBuilder 2025 builds on SAP PowerBuilder 12.6 and has excellent backwards compatibility, allowing customers running PB 6 - 12.6 to directly migrate with minimal modifications to their code.
This is important because for many development teams, the best first step before undertaking a complete rewrite is to implement an upgrade-first modernization strategy.
5) Appeon: DataWindow Converter
If your application heavily relies upon DataWindows, this is one of the most important documents on the internet.
The Appeon website explains that the tool converts PowerBuilder DataWindow Object(s) and other objects/models into C# data objects and types which may be used as SnapObject(s) in C# tools.
Therefore, if you want to reuse existing business logic instead of rewiring everything from scratch, this will greatly assist your development teams.
6) Appeon: PowerServer installable cloud app overview
If you want to deploy using the cloud, and you don't want to do a complete re-write, you can find this guide useful.
According to Appeon, a cloud-based application needs to be created using both static files (such as the client application, launcher and runtime) and dynamic data (for example, Document Object Model (DOM) elements).
Also, PowerBuilder DataWindows and embedded SQL will be translated into C# models that are provided by REST/JSON APIs.
7) Appeon’s 32-bit to 64-bit migration guide
While many modernization initiatives are focused on updating the architecture only, rather than migrating to an entirely new platform, this guide is intended to help you understand your migration justification; your ROI; your database connections; your PBNI; your testing/ debugging; your deployment; any unsupported features; and your step by step migration work.
The other point to note is that with PowerBuilder 2022 onwards, you can now run and debug 64 bit apps directly within the IDE, so this guide is particularly useful for any organization moving to modernize older desktop workloads.
8) Appeon’s PowerServer Web APIs concepts documentation
PowerServer employs web-based APIs, which serve as the backend for PowerBuilder apps.
PowerServer also converts DataWindows, DataStores and Dynamic DDDWs (DDDWs) into C# Models and creates RESTful APIs for performing CRUD functions over HTTP using JSON for the data exchange.
This resource is a valuable resource for readers who are looking at migration and looking to understand how a PB application can run in a more current n-tiered or web-based architecture.
9) Appeon’s migration webcast and case-study video
This is a successful migration from PowerBuilder version 12.5 to version 2022 R3 with a discussion regarding the reasons for migrating and how deprecated/obsolete functionality has been addressed through this migration process.
The session will also include a demonstration utilizing the HTTPClient and PBDOM objects for accessing web services and retrieving XML data to provide the reader with a more practical view than is available via documentation.
Community source for planning questions
10) Appeon Community discussion on migration planning
This isn't a substitute for official documentation; however, it’s a great resource if you’re interested in the types of planning inquiries real teams generally ask prior to beginning.
Participating in community discussions can help you find issues that relate to rollout, testing and sequencing ahead of time, as well as provide you with an alternative view, before verifying any decisions with official docs.
Final takeaway
There is no one-size-fits-all answer to this question. Rather, a collection of articles that address 4 questions surrounding migration process are included in the stack. They are:
1) What is the supported way to go?,
2) What is the correct migration path?,
3) How can I handle both DataWindows and business logic?,
4) How do I minimize the risk of delivery?
Top comments (0)