PowerBuilder Modernization:
Stay current on Appeon, or move off the DataWindow.

PowerBuilder is still developed: Appeon ships PowerBuilder 2025 R2, and the 2022 R3 long-term support release is supported no sooner than 2029. So the decision is real, not forced. Staying and upgrading is reasonable when the application is sound. Migration is justified for web delivery, a C# team, or DataWindow-heavy logic that must move. The assessment decides which.

Book a free 1-hour consultation →

At a glance

Legacy sources: PowerBuilder 5 to 9 · PowerBuilder 10 to 12.x · PowerBuilder 2017 to 2022 · PowerScript · DataWindow · PBL and PBD files · PB.NET (discontinued) · EAServer
Modern targets: PowerBuilder 2022 R3 LTS · PowerBuilder 2025 R2 · PowerServer · C# .NET 10 · ASP.NET Core · SQL Server · PostgreSQL
First step: Free 1-hour consultation, then a fixed-scope assessment
U.S. delivery: 100% U.S. citizen workforce, U.S.-soil delivery

What to know before you modernize

What PowerBuilder is and who still runs it

PowerBuilder 1.0 shipped in July 1991 from Powersoft, which Sybase bought in 1995. SAP acquired Sybase in 2010, and in July 2016 SAP and Appeon agreed that Appeon, an independent company, would develop, sell, and support the product. It is a client/server tool: PowerScript is the language, windows and menus are the interface, and the DataWindow ties a screen, a SQL statement, and an update to a database in one object. That combination made PowerBuilder very productive for forms-over-data systems. Those systems are still running because they work and because the tool never stopped being sold. The risk is usually not the product. It is the version, the dependence on the DataWindow, and the shrinking pool of people who can maintain the code.

Which PowerBuilder you have, and what it implies

The version tells us where the work starts. PowerBuilder 12.5 and 12.6 are the SAP-era releases. PowerBuilder 2017 and later are based on the 12.6 code base, so a 12.x application usually opens in a newer release without a rewrite. Versions before 12 are assessed individually, because libraries and external calls from that era are where upgrade problems usually appear. PowerBuilder 2019 added C# targets, 2022 R3 in January 2024 was designated long-term support, 2025 arrived in May 2025, and 2025 R2 was released in June 2026. Applications also differ by deployment: plain client/server, a three-tier design with EAServer, or a web DataWindow deployment, the last two of which have been removed from the product. The first deliverable is a list of every PBL and PBD, its source version, and its deployment pattern.

Support and lifecycle: Appeon's published dates

Appeon's policy gives non-LTS versions at least 24 months of standard support and LTS versions at least 60 months, with end of life typically 12 and 24 months after end of mainstream maintenance. As published in Appeon's update matrix on the date of this page, PowerBuilder 2022 R3 is the LTS release, with maintenance ending no sooner than January 8, 2029 and end of life no sooner than January 8, 2031. PowerBuilder 2025 has maintenance ending June 3, 2027 and end of life June 3, 2028. Dates for 2025 R2 are not yet published. PowerBuilder 2022 and 2022 R2 reached end of mainstream maintenance on May 7, 2026, with end of life on May 7, 2027, and Appeon recommends 2022 R3 or above. If you are on 2022 or older, the support clock is the first thing to check.

Windows 11, 64-bit, and the toolchain

The current PowerBuilder IDE supports Windows 11, and applications built with it, including the runtime, support Windows 11 and Windows Server 2025. PowerScript applications can be compiled as native 64-bit Windows programs, though any third-party DLLs you call must be available in 64-bit form. The IDE itself is a 32-bit process even though it can target 64-bit. Older deployed executables built with 12.x or earlier are 32-bit and run on 64-bit Windows through WOW64, but old database clients, ActiveX controls, and printer drivers are where those installs tend to break. Moving to a current release is therefore mostly a driver and external-DLL exercise, not a language one. Appeon states that upgrades usually need little to no code change, and the assessment checks that statement against your actual PBL contents.

PowerBuilder .NET, C# targets, and what happened to them

PowerBuilder has had several .NET stories. PB.NET, the Visual Studio-hosted version, and WPF projects were discontinued, and Appeon's FAQ says PowerBuilder 2017 and later descend from the 12.6 code base. Windows Form targets, EAServer targets, and the Web DataWindow were also removed. From PowerBuilder 2019, Appeon introduced C# targets: managed C# code compatible with .NET Core, built in the separate SnapDevelop IDE, with a PowerScript-to-C# migration tool. If your application was built around PB.NET, EAServer, or Web DataWindow, it needs more than a version upgrade, and those are the cases where migration to current .NET is most likely to be the better route. For a plain client/server application, none of this applies.

PowerServer: web and cloud deployment from the same code

PowerServer is Appeon's route to internet-accessible, n-tier deployment. It places a REST API middle tier between the PowerBuilder client and the database, and the server runs as a native 64-bit process on .NET. The 2025 R2 release adds Windows Authentication, encrypted connection properties, and .NET 10 support. Appeon's product page also lists CloudPro, which deploys client/server applications as Installable Cloud Apps through a REST API architecture. The honest description is that it moves the database connection off the user's PC and onto a managed API, which helps with security and remote work, while the user interface is still a PowerBuilder client. It is not a browser application. If the requirement is a browser or mobile interface, PowerServer does not by itself meet it, and that requirement is the strongest argument for migration.

Data layer: native drivers, ODBC, and SQL Anywhere

PowerBuilder connects through native drivers, ODBC, and OLE DB. The current release documents native interfaces for Microsoft SQL Server (via OLE DB), Oracle, SAP SQL Anywhere (via ODBC, version 17.x), SAP ASE, PostgreSQL, MySQL, and Informix. That is wide coverage, and it means a database change does not by itself force you off PowerBuilder. A move from Sybase ASE or SQL Anywhere to SQL Server or PostgreSQL is mostly a matter of re-pointing the connection, finding vendor-specific SQL embedded in DataWindows and scripts, and testing transaction and locking behavior. Embedded SQL, stored procedure calls, and DataWindow SQL are inventoried separately. If the plan is migration to .NET, the schema and stored procedures usually stay, which is why the data layer is moved first.

The DataWindow is the central problem

A DataWindow is a screen, a result set, a set of edit rules, and an update statement in one object, so PowerBuilder applications often hold their business logic there. That is exactly why migration is hard. Behaviors that are hardest to reproduce in .NET or the web include the three data buffers (Primary, Filter, Delete) and per-row, per-column item status that drives which rows are inserted, updated, or deleted; Update properties that decide the generated SQL and key handling; computed fields and expressions written in DataWindow syntax; dynamic changes at runtime through Modify and Describe strings; retrieval arguments and dropdown DataWindows nested in columns; grid, freeform, tabular, group, crosstab, and graph presentations; and pixel-accurate printed reports. Each must be catalogued per DataWindow before a target is chosen, because the number of distinct patterns determines the effort.

Rewrite vs strangler fig →

The paths: stay current, bridge, or migrate

Appeon still develops and supports PowerBuilder, so staying is a legitimate answer. Stay and upgrade when the application works, the DataWindow logic is stable, and you can keep PowerBuilder skills available: move to 2022 R3 LTS for the longest published support window, or 2025 R2 for the newest features, and fix drivers and external DLLs. Add PowerServer when remote access and API security are the goal. Migrate when you need a true browser or mobile interface, a C# team, or integration that PowerBuilder serves poorly, or when you are on PB.NET, EAServer, or Web DataWindow. A bridge is a practical middle: expose the database logic as APIs, build new modules in .NET, and keep the PowerBuilder client for the rest until each part is replaced.

Keeping it running and proving parity

These systems usually run daily operations, so migration is incremental. The database is kept in place and shared by the old and new applications, and modules move one at a time, with the old screen retired only after its replacement matches. Parity is measured per DataWindow: the same retrieval arguments return the same rows, edits produce the same inserts, updates, and deletes, expressions give the same values, and printed reports match page by page. We capture real inputs and outputs from the current system, run both versions against the same data, and compare. A rollback path is kept for every cutover. The same method applies to an upgrade within PowerBuilder, where the check is whether the recompiled application behaves identically on the current runtime.

Start with an assessment for a PowerBuilder codebase

For a PowerBuilder codebase the read-only assessment inventories every PBL and PBD with its source version, the number and type of DataWindows and their presentation styles, embedded SQL and stored procedure calls, PowerScript object counts, external DLL and OLE calls, EAServer, PB.NET, or Web DataWindow dependencies, database drivers and the database engine in use, reports, deployment and installer method, and test coverage. Nothing is run against production. The result is a written recommendation: stay current on Appeon's release, add PowerServer, bridge, or migrate, with reasons and the DataWindow complexity map attached. The fee is quoted after the free 1-hour consultation and is creditable toward a later modernization project.

About the assessment →

Deliverables

  • Written recommendation: stay current, add PowerServer, bridge, or migrate
  • Inventory of PBLs, PBDs, source versions, and deployment patterns
  • DataWindow complexity map by presentation style and behavior
  • Upgrade plan to PowerBuilder 2022 R3 LTS or 2025 R2 with driver and DLL fixes
  • Data-layer plan for SQL Anywhere, ASE, Oracle, or SQL Server to a current database
  • Parity test plan and cutover sequence that keeps the system in service

Common questions

Is PowerBuilder still supported?

Yes, by Appeon. The current release is PowerBuilder 2025 R2, and 2022 R3 is the designated long-term support release with maintenance ending no sooner than January 8, 2029. PowerBuilder 2022 and 2022 R2 passed end of mainstream maintenance on May 7, 2026. Older SAP-era releases are not what Appeon is fixing now.

Does PowerBuilder run on Windows 11?

Yes. Appeon documents Windows 11 for the current IDE, and Windows 11 and Windows Server 2025 for applications and the runtime. An older 32-bit executable generally runs on Windows 11 through WOW64, but old database clients, ActiveX controls, and printer drivers are the common failure points.

Should we upgrade PowerBuilder or migrate to .NET?

Upgrade when the application is sound, DataWindow logic is stable, and PowerBuilder skills are available. Migrate when you need a browser or mobile interface, a C# team, or integration PowerBuilder does not serve well, or when you depend on discontinued features such as PB.NET, EAServer, or Web DataWindow. Because Appeon still ships the product, staying is a legitimate answer.

What is PowerServer and does it make PowerBuilder a web app?

PowerServer adds a REST API middle tier on .NET between a PowerBuilder client and the database, allowing internet-accessible deployment. It improves security and remote access, but the user interface remains a PowerBuilder client. If you need a real browser or mobile interface, that is a migration decision rather than a PowerServer feature.

Can PowerBuilder be 64-bit?

Yes. PowerScript applications can be compiled as native 64-bit Windows programs, and any third-party DLLs they call must also be 64-bit. The IDE itself runs as a 32-bit process. PowerServer applications can be built as 32-bit or 64-bit, and the server runs as a 64-bit process.

Can we keep running during a migration?

Yes. The database stays in place and is shared. New modules are built in .NET while the PowerBuilder client continues to serve the rest. Each screen is retired only after its replacement has matched the old output on the same data, and every cutover has a rollback path.

How long does a PowerBuilder modernization take and what does it cost?

It depends on scope. Project work ranges from a few weeks (virtualization) to several months (re-architecture). Every engagement starts with a free 1-hour consultation. Price and schedule are fixed after the fixed-scope Legacy Software Assessment, and the assessment fee is creditable toward a later modernization project.

Do we have to rewrite all the DataWindows?

Not for an upgrade, because DataWindows carry forward within PowerBuilder. For a migration, each DataWindow is classified by presentation style and behavior, and simple retrieve-and-edit grids are rebuilt from their definitions. The expensive ones are those with dynamic Modify strings, complex update properties, crosstabs, or printed layouts. The assessment counts them.

Sources

Not sure where to start?

Start with a fixed-scope Legacy Software Assessment: a read-only review of your application’s source, database, configuration, logs, and architecture, ending in findings with evidence and a written recommendation. Quoted after the free 1-hour consultation; creditable toward a subsequent modernization project.