ServicesPowerBuilder Modernization
B · Evolve

PowerBuilder Modernization Without a Risky Rewrite

Phased, reversible upgrades for long-running PowerBuilder applications. We modernize the parts that pay back — and leave alone the parts that don't. Production stays running throughout.

  • PB 9 → 2025
  • Appeon migration
  • PowerServer · PowerClient
  • Phased rollout
What's included

Concrete deliverables in a Modernization engagement

Modernization is a sequence of small, reversible decisions — not a single big bang. Each artefact below is a real work product you receive, with rollback options for every step.

Codebase, architecture and risk assessment

Dependency map, third-party DLL inventory, runtime-version exposure, business-critical workflows. The written input that informs every later decision.

PowerBuilder version upgrade plan

Concrete steps from your current PB version (often 9, 10.5, 11.5 or 12.6) to a chosen Appeon target (2017, 2019, 2022 or 2025). With rollback gates between each stage.

Appeon migration path (Sybase → Appeon)

Compatibility audit, deprecated-feature replacement plan, runtime distribution change, licensing reconciliation. Specific to your codebase, not a generic checklist.

PowerServer / PowerClient readiness report

Honest assessment of whether the application is a good candidate for PowerServer (web/cloud) or PowerClient (cloud-deployed thick client) — and what would need to change first.

UI modernization without redesign

Visual refresh that respects user habits: cleaner DataWindow presentation, modern fonts, improved accessibility — without retraining users on a new flow.

Build, deployment and installer refresh

Modernized build chain, signed installers, certificate management, runtime distribution strategy that matches your IT environment in 2026, not 2008.

Database compatibility plan

Oracle 19c / 23ai, SQL Server 2022, PostgreSQL 16 — the database side of any PB upgrade. We map character-set, ANSI/ODBC and SQL-dialect risk before the upgrade starts.

Executive-ready summary

A 4–8 page document the CTO can hand to the board: what is happening, what it costs, what the risks are, what 'done' looks like.

When this engagement fits

Typical situations behind a Modernization call

Modernization rarely starts because someone wakes up wanting it. It starts when something external forces the conversation. These are the four most common triggers.

Case · 01

Leadership is considering a full rewrite

Someone is pushing 'rewrite in .NET / Java / web'. The number scares you. You need a sober, costed alternative on the table before the decision is made.

Case · 02

Sybase-era PB and end-of-support pressure

On PB 11.5 or 12.6, no upgrade path agreed, getting nervous about runtime support, security and the talent market. We map the route to a current Appeon release.

Case · 03

Oracle, SQL Server or OS end-of-life

Database or platform EOL is on the calendar. PB compatibility risk is now the project bottleneck. Modernization aligns the application with the new platform.

Case · 04

Deployment chain has rotted

Build is fragile, installer broken, runtime drift across machines. The application still runs but you can't ship a fix without praying. Modernization rebuilds that foundation.

How we work

Four phases: Assess → Decide → Modernize → Evolve

Each phase produces a written artefact you can act on independently. You can stop after Assess or Decide — most engagements continue, but the option is real.

01

Assess

2–4 week scan: codebase, architecture, database, dependencies, business-critical workflows. Output: written risk and readiness report.

2–4 weeks · fixed fee
02

Decide

Three modernization options ranked by cost, risk and timeline. We strongly recommend one — but the choice is yours, and we document the trade-offs.

1 week · written
03

Modernize

Phased upgrade. Every milestone is reversible: if a stage fails, we roll back without losing the others. No 'big bang go-live'.

phased · scoped
04

Evolve

Post-modernization: documentation handover, optional retainer to keep the gains. The system runs better and stays that way.

long-term · optional
Engagement shape

Fixed-fee assessment, then phased implementation

Modernization almost always starts with a fixed-fee assessment — the cheapest way to find out whether the bigger investment makes sense. Implementation comes after, scoped to the chosen path.

Plan A

Modernization assessment

Fixed-fee, fixed-timeline review of the application. Risks, dependencies, upgrade path, three implementation options. Ends with a written report you can act on independently.

  • Codebase & architecture review
  • Risk & dependency report
  • 3 implementation options
  • Executive-ready summary
Fixed fee · 3–6 weeks
Plan C

Targeted modernization

One specific modernization slice: PowerServer pilot, installer refresh, Appeon-only migration. Fixed scope, fixed fee. For when the full program isn't on the table yet.

  • Single workstream
  • Fixed scope and fee
  • 4–12 weeks
  • Hand-off documentation
Fixed fee · scope-dependent
Frequently asked

Answers to common questions about PowerBuilder Modernization

Should we modernize or rewrite?

Rewrites of mature PowerBuilder applications fail more often than they succeed — typically because the business logic encoded in the DataWindows and event chains is far more valuable than anyone realizes. Modernization is almost always cheaper, lower-risk and preserves what works. We will tell you honestly if your case is the exception.

How long does PB 12.6 → 2025 actually take?

For a typical 200–500 DataWindow enterprise application: assessment 3–4 weeks, phased implementation 4–9 months. The variance comes from third-party DLLs, custom controls and database-side coupling — which is exactly what the assessment phase quantifies before you commit.

Can we modernize while the system is in production?

Yes — and we strongly prefer it. Each phase ships a reversible change that can be deployed or rolled back independently. There is no 'modernized branch' running for months in parallel with production. That model breaks more often than it works.

Do we have to move to PowerServer?

No. PowerServer is a good fit for some applications and a bad fit for others. Our readiness report tells you honestly which category yours is in — and what would need to change first. Plenty of modernized applications stay as thick clients and that's fine.

What does this typically cost?

Assessment: fixed-fee, similar to a typical management-consulting engagement. Implementation: scoped per phase, billed monthly, sized to your codebase. We deliberately avoid quoting a number publicly because PowerBuilder application sizes vary by two orders of magnitude — but we will quote a fixed price after the assessment.

Contact

Considering modernization?

Send a short description of your PowerBuilder system — current version, database, deployment, top concern. We'll reply within one business day with a practical next step. Most engagements start with a fixed-fee assessment.

What we need first: PowerBuilder version, target (or 'don't know yet'), database, what is forcing the conversation now. Enough to suggest a path.
NDA-friendly · MSA-ready · GDPR · References on request · Hourly or fixed-fee