PowerBuilder 9 to 2025: A Pragmatic Upgrade Guide

Twenty years after Sybase released PowerBuilder 9.0, a surprising number of mission-critical enterprise applications still run on it. That is not a failure — it is a sign that the platform aged well and the business logic encoded in those applications turned out to be more valuable than anyone predicted. But in 2026, staying on Sybase-era PowerBuilder is becoming actively expensive, and the question is no longer whether to upgrade. It is which path and when.

This article gives you the pragmatic map. It is not a sales pitch and it is not a panic piece. The intent is to leave you with a defensible plan you can take to leadership in 30 minutes of reading.

Why upgrade at all (the honest version)

Three forces matter, in roughly this order:

1. Talent. The pool of developers fluent in Sybase-era PowerBuilder shrinks every year. Senior engineers who learned PB in the late 1990s are retiring; junior engineers do not pick it up. Hiring becomes harder, then expensive, then impossible — in that order.
2. Platform compatibility. Modern Windows, Citrix environments, terminal services, certificate stores and ODBC drivers have all moved on. PB 9 and 10 increasingly need specific workarounds to run cleanly on Windows 11 / Server 2022.
3. Security. Sybase-era PowerBuilder runtimes no longer receive security patches. For most internal LOB applications this is a minor risk; for systems that touch the internet or handle regulated data it is increasingly hard to defend in an audit.

Notice what is not on this list: feature pressure. Modernizing to PowerBuilder 2025 rarely unlocks new features your users were asking for. The upgrade is about platform health, not product capability. That framing matters when you talk to leadership.

The version map you actually need

PowerBuilder versions split cleanly into two eras with different owners and slightly different release cadences:

• Sybase era: PowerBuilder 9 (2003), 10, 10.5, 11, 11.5, and 12.6 (2014). End of mainstream support: 2016. End of any support: 2019.
• Appeon era: PowerBuilder 2017, 2017 R2, 2017 R3, 2019, 2019 R2, 2019 R3, 2022, 2022 R2, 2022 R3, and current PowerBuilder 2025. Actively developed and supported.

Almost every legacy upgrade we see starts on 9, 10.5, 11.5 or 12.6 — and lands on 2022 or 2025. The intermediate Appeon releases (2017, 2019) are almost never the right target in 2026; they have less support runway and you are committing to another upgrade in two years.

Three upgrade paths

Pick one based on your risk appetite and how decoupled your codebase already is.

Path A: Incremental (PB N → N+1 → N+2 → … → 2025)

Move through every major release. Slower, more bugs surfaced per step, but each step is smaller. Sounds safer; in practice it usually is not. Recommended only for unusually fragile codebases with deep third-party-control dependencies.

Path B: Leapfrog (PB 12.6 → PB 2025 directly)

Skip all intermediate versions, do the entire compatibility work once. This is the path we recommend in 80% of cases. You write one regression suite, do one round of third-party-DLL testing, ship one upgrade. The total work is less, and the surface area for surprises is smaller because there is exactly one transition rather than five.

Path C: Parallel rebuild

Build the modernized version alongside production, cut over once. Rarely the right choice for a single PowerBuilder application because keeping two copies in sync is expensive. Reserved for the case where the original codebase is so degraded it would slow the upgrade more than starting from a clean target.

What actually breaks

From the dozens of upgrades we have shepherded, here is the real list, ranked by how often it surfaces as a blocker:

1. Third-party DLLs and OCX controls. By far the number-one source of pain. ActiveX controls written in the late 1990s frequently do not have 64-bit versions and were never recompiled for modern Windows. Either find replacements, re-implement, or stay 32-bit (an option current PowerBuilder still supports).
2. Deprecated PowerScript functions. A handful of functions were removed between Sybase 12.6 and Appeon 2017+. The compiler tells you which ones; the fixes are mostly mechanical.
3. Database driver versions. ODBC drivers, Oracle client versions, MSSQL native client deprecation. Often the intermediate dependency you forget about until release day.
4. DataWindow rendering differences. Print and PDF output sometimes shifts by a pixel or two between versions. Stable for screen rendering; matters if you have invoices, regulatory forms or specific layout requirements.
5. Build chain and installer. The build server, the installer toolchain (Wise / InstallShield / WiX), code signing certificates — all need attention. Often the actual long-pole work, underestimated because it is not PowerBuilder code per se.

The next six months

If you are reading this and thinking okay, but where do I actually start, here is the answer:

1. Weeks 1–4: Assessment. Hire (or use internal) PB senior to spend three to four weeks producing a written compatibility and risk report. Output is a document, not a working upgrade. This is the cheapest possible commitment.
2. Weeks 5–6: Decide. The assessment gives you a number and a path. You either commit to the upgrade, defer, or re-scope. Either way you are now operating with real data.
3. Months 2–9: Implement, in phases. Each phase is independently reversible: third-party DLL replacement, then runtime upgrade, then deployment chain, then user rollout. No big-bang go-live.

The whole sequence is designed so that you can stop at any point with a clear understanding of what you got for what you spent.

What this article isn't. A line-by-line compatibility checklist or a list of every deprecated PowerScript function. Appeon publishes the specifics version-by-version and they change with each release. The intent here was to give you the shape of the decision, not a substitute for the platform docs.