PowerBuilder on Windows 11 and Windows Server 2025

A platform refresh is usually what forces the question: the desktop fleet is moving to Windows 11, or the terminal servers are being rebuilt on Windows Server 2025, and someone has to sign off that the PowerBuilder application still runs. The honest answer is yes, on current PowerBuilder — but there are a few specific things to verify, and one rule that surprises teams every time. Here is the whole picture.

Is PowerBuilder supported on Windows 11 and Server 2025?

For current PowerBuilder (2025 / 2025 R2), the answer is a clean yes — with one distinction that matters. Appeon lists Windows 11 for both the IDE and the runtime, and Windows Server 2025 as a runtime target. In plain terms: you build the application on a Windows 11 workstation, and you can run the deployed application on either Windows 11 desktops or a Windows Server 2025 host. If your version predates this, the fix is not Windows — it is the PowerBuilder upgrade, which is a different project (see the version and support-lifecycle reference).

“Runtime only” on Server 2025 — what that means

A lot of PowerBuilder applications don't live on individual desktops at all — they run on a terminal server (RDS) or a Citrix farm, and users connect to a published session. That is exactly the scenario “runtime support for Windows Server 2025” is describing: the deployed executable and its PowerBuilder Runtime are supported on the server. What is not in scope is installing the PowerBuilder IDE on Windows Server 2025 to develop there — that is not a supported configuration, and there is no good reason to want it. Keep development on Windows 11 and treat the server purely as a host.

The catch that surprises teams: runtime-version matching

This is the single thing that trips people up during a Windows move, and it has nothing to do with Windows itself. A PowerBuilder application runs against the exact runtime version it was compiled with. Rebuilding the terminal server, re-imaging a workstation, or “the new machine already has a PowerBuilder runtime on it” are all ways to end up with a runtime that does not match the build — and the app fails to start or misbehaves in ways that look like an OS problem but aren't.

The clean way to do this is Appeon's Runtime Packager (or an MSI that bundles the runtime), so the correct runtime version travels with the application instead of relying on whatever happens to be on the target machine. On a Windows 11 rollout or a new Windows Server 2025 image, make the matching runtime part of the deployment package — not a manual afterthought.

Older PowerBuilder (9–12.6) on Windows 11

If you are still on a Sybase-era version, Windows 11 is technically an unsupported combination — but in practice these applications usually run. The work is in four predictable areas, none of which requires a rewrite:

• High-DPI scaling. On a 4K laptop at 150–200% scaling, an old application can render blurry or with clipped controls. Current PowerBuilder has per-monitor DPI awareness; older builds often need an application-manifest or a compatibility-mode setting to look right.
• Application manifest / UAC. Very old executables can trip Windows 11's stricter UAC and file-virtualization rules, especially if they write to Program Files or the registry. A proper manifest and moving writable data to %AppData% resolves most of it.
• OCX and DLL registration. Third-party ActiveX/OCX controls and helper DLLs need to be present, the right bitness, and registered. Missing Visual C++ redistributables are a common silent cause of “works on my machine, not on the new image”.
• Legacy database drivers. The older ODBC/OLE DB drivers an old app expects may not ship with Windows 11 or Server 2025 — which leads straight into the next point.

Database drivers are where it usually bites

More Windows-migration incidents trace back to the database driver than to PowerBuilder itself. Current PowerBuilder connects to SQL Server through the Microsoft OLE DB driver (MSOLEDBSQL), and there are three things to line up on a new Windows host:

• Driver version. Install a supported MSOLEDBSQL build. A newer major driver picked up automatically by the OS image can behave differently than the one your app was tested against — pin the version you validate.
• Bitness. A 32-bit application needs the 32-bit driver; a 64-bit build needs the 64-bit one. Mixed bitness produces a “driver not installed” error even when the driver is clearly there.
• TLS / encryption. Windows Server 2022 and 2025 default to stricter TLS. A connection string that worked for years can start failing on a self-signed or expired certificate until Encrypt / TrustServerCertificate are set correctly.

The same principle applies to Oracle — the driver and its OS prerequisites do more work than people expect, which we cover in PowerBuilder + Oracle 19c compatibility.

A short pre-move checklist

1. Confirm the PowerBuilder version and whether it officially covers your Windows target. On 2025 / 2025 R2 you are covered; on older versions, plan the upgrade as its own track using the 9 → 2025 upgrade guide.
2. Package the matching runtime with the application so the new Windows 11 or Server 2025 image never relies on a runtime that happens to be present.
3. Test high-DPI rendering on the actual monitors and scaling users will have — not just the developer's screen.
4. Validate database drivers — version, bitness and TLS — against the production database from the new host.
5. Exercise third-party OCX/DLL controls and printing / PDF DataWindow output, the two areas most likely to surface a missing dependency.

Bottom line. Current PowerBuilder is supported on Windows 11 (develop and run) and Windows Server 2025 (run). The failures people blame on the OS are almost always one of three things: a runtime that doesn't match the build, a database driver mismatch, or high-DPI rendering on old code. Handle those three and a Windows move is a routine project, not a risky one.