Modernize PowerBuilder or Rewrite in .NET? A Decision Framework

Sooner or later, somebody in leadership asks: why don't we just rewrite this in .NET? (Or Java, or React, or whatever the team knows.) The honest answer takes more than a tweet — and the honest answer matters, because most rewrites of long-running PowerBuilder applications fail. Not just go over budget. Genuinely fail, in the sense of getting cancelled, scaled back to a wrapper around the original, or shipped with worse functionality than the system they replaced.

This article is the framework we use to give that answer.

Why most rewrites fail (and the one reason that matters most)

The published industry literature on rewrite failure rates is sobering — Standish CHAOS reports and similar studies put major rewrite failure rates above 50% across all technology stacks. For PowerBuilder applications specifically the rate is, in our experience, considerably worse — and the failure mode is almost always the same.

The reason is not that .NET is bad, or that the rewrite team is junior, or that the project is underfunded. The reason is that in a mature PowerBuilder application, an enormous amount of business logic lives inside DataWindows, event chains, validation rules, and the database. None of it is in a place a fresh development team would think to look. By the time they discover rule number 847 — the one about how French customers get a different tax treatment if the invoice crosses month-end — they have shipped a system that the actual users refuse to use.

The polite name for this phenomenon is tacit knowledge. The less polite name is the reason the original developers retired comfortable.

The two decisive questions

Before any rewrite-versus-modernize decision, two questions decide which path is actually appropriate:

Question 1: Has the job of the application changed?

Is the PowerBuilder application still doing essentially the same thing it was designed for, just in a current environment? Or has the business genuinely moved to a different shape — mobile-first, multi-tenant SaaS, real-time collaborative — that the original architecture can't reach?

If the job is the same → modernize. The accumulated business logic is an asset; preserving it is the point.

If the job has fundamentally changed → rewrite, but only the parts that need the new shape. Often the right answer is a hybrid: a new system handling the new use cases, with the PB system continuing to handle what it does well.

Question 2: Can you afford to be without the system for the rewrite period?

A rewrite of a 20-year-old enterprise PowerBuilder application typically runs 18–36 months. During that period you are running the old system in parallel, paying for both, synchronizing data, and accumulating the natural divergence that comes from two systems with the same intent and different code. If a calendar event hits during the rewrite — Oracle EOL, OS upgrade, regulatory change — you have to do that work twice.

Modernization stays in production throughout. There is no parallel-run period. The risk profile is fundamentally different.

The hidden cost: tacit knowledge extraction

Suppose you decided to rewrite anyway. The single largest cost — and the one most often underestimated — is the work of extracting the business logic from the PowerBuilder application into a form a new team can build against.

This is rarely budgeted properly because it doesn't look like "real" work. It is sitting in meetings, reading DataWindow filter expressions, tracing event chains, getting the right person to explain why rule #847 exists. In practice this work alone takes 30–50% of the rewrite timeline. Many rewrites underbudget it by an order of magnitude.

Modernization avoids this cost entirely. The logic stays where it is; the runtime around it changes.

When rewrite IS the right answer

We have advised companies to rewrite. Three situations:

• Business shape change — the company is moving to a fundamentally different operating model (e.g. from internal-only desktop application to multi-tenant SaaS for external customers). The PB application cannot reach the new shape, and modernizing it to try would be more expensive than building the new shape from scratch.
• Codebase rot beyond a threshold — rare, but real. If the PB codebase has been damaged by years of careless modifications, missing source control, lost .pbl files, the modernization work itself becomes harder than starting clean. A senior PowerBuilder review can identify this honestly.
• Compliance or audit blocker — a regulator or insurer has put unambiguous requirements on the runtime (e.g. cannot run any unsupported software, full stop) and there is no exemption. Sometimes this is genuinely binding.

Outside these three, the answer is almost always modernization.

A decision matrix

Lay your application on these dimensions:

• Business logic complexity: light / moderate / deep
• Time the application has been in production: under 5 years / 5–15 years / 15+ years
• Job-shape change: none / partial / fundamental
• Codebase health: good / mixed / poor
• Team familiarity with the domain: deep / partial / lost

If most rows skew toward the left or middle, modernize. If most rows skew right, the rewrite case is real — but get an independent review first.

What modernization actually looks like

Concretely: a 6 to 18 month program that runs alongside production, ships phased improvements (PowerBuilder version upgrade, deployment refresh, optional UI modernization, optional cloud delivery via PowerServer/PowerClient), and ends with a system that has the same business behaviour and a modern operational profile.

Throughout, production stays in production. Each phase is reversible. The total cost is typically 10–25% of an equivalent rewrite. The risk profile is dramatically lower. Most companies wish they had done this two years earlier.

The one thing leadership needs to hear

Reframe the conversation:

The question is not "PowerBuilder versus .NET". The question is "preserve the working business logic, or rebuild it from scratch and hope it survives". Phrased that way, modernization is usually the conservative, risk-managed choice — and rewrite is the swing for the fences.

Sometimes the swing makes sense. Usually it doesn't.

If you are the one writing the recommendation. We do these reviews independently — usually a 2-week fixed-fee engagement that ends with a written document. The written form is intentional: it gives the CTO something to circulate, and it forces us to commit to an opinion.