Migration of PowerBuilder applications from one version of PowerBuilder to another is often viewed in one of two extremes:
- It’s a push-button affair that shouldn’t be viewed with any more gravity than changing one’s socks
- It’s a journey fraught with more unknown dangers, perils and evils than Frodo’s journey to return The Ring to Mount Doom
My own experience suggests a different range:
- When developing PBL Peeper for multiple versions of PowerBuilder, I’d often perform multiple migrations each day without problems
- When migrating perfectly well written applications, they can run into problems in changed functionality in PowerBuilder
- Migrating applications that are poorly written or developed with bad practices can bring these problems to light
This guide is meant to minimize any potential problems that may arise. It is entirely possible, if your application is destined to migrate smoothly, that reading this guide will end up taking you longer than the migration process. In fact, it is almost guaranteed that the safety net I prescribe in the Migration Steps will take longer to build than the actual migration process. This guide is primarily helpful if you believe that whatever can go wrong will happen to you.
Because of the testing that a migration should cause, it is not an inexpensive process. Choosing a target version of PowerBuilder to maximize your life on a particular version of PowerBuilder is important.
It’s not inconceivable that moving forward was a mistake for you, and now you have to move to a previous major version of PowerBuilder. It’s not a trivial process. This document on Backward Migration will help you identify the potential magnitude of the task, may help you head off some of the problems.