PowerBuilder ↔ target architect
Bridge between PowerScript/DataWindow and the target ecosystem (.NET, Java, TypeScript), pattern mapping, REST API design
Modernization path
Replace a PowerBuilder application with a modern architecture.
Migration of PowerBuilder applications (PowerScript, DataWindow, PBL) to .NET Core, TypeScript, or Java, under the ATLAS methodology. Screen capture, characterization tests, pattern-by-pattern migration, parity audit, REST API exposure for cloud integration and agentic workflows.
Key figures
30-50%
share of total UI effort represented by DataWindow porting (to include in initial scoping)
50-150
DataWindows in a typical PowerBuilder estate, all mapped from the Intake phase
By batches
incremental delivery, duration set at scoping
ATLAS methodology applied
From scoping to deployment, five structured phases.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
- 01Phase 1
Scoping
ATLAS stepsE1 Intake · E2 Discovery · E2b Functional specUnderstand the PowerBuilder estate: projects, screens, DataWindows, PBL, DataStores, database integrations. Rebuild a functional analysis from the code. Define scope, constraints, success criteria, target architecture choice (.NET / Java / TypeScript, web SPA vs WinForms).
Phase deliverableEstate inventory + functional spec + pricing with explicit range - 02Phase 2
Capture & dependencies
ATLAS stepsE2e Capture · E3 Dependency mappingExhaustive DataWindow mapping (source SQL, calculated columns, validation rules, onChange/onBlur events), PBL packages, PowerScript scripts, shared DataStore dependencies. Identification of database integrations (SQL Anywhere, Sybase ASE, Oracle) to migrate.
Phase deliverableReference DataWindows and screens bench + complete dependency map - 03Phase 3
Target architecture
ATLAS stepsE4 Target architecture · E4b Pre-migration testsDesign target architecture: .NET Core / Java Spring Boot / TypeScript Node.js, cloud PostgreSQL or SQL Server database, containerization, OpenAPI-documented REST API exposure, separate SPA frontend or WinForms. Cloud strategy and observability. Prepare characterization tests.
Phase deliverableSigned target architecture + test suite + UI mockups if web redesign - 04Phase 4
Migration & parity
ATLAS stepsE5 Migration · E6 Parity validationTranslate pattern by pattern: DataWindow → AG Grid/Telerik/JavaFX TableView, PowerScript → C#/Java/TypeScript, DataStores → entities/repositories, PBL → target packages. Incremental subsystem migration, parallel runs, internal parity audit per batch.
Phase deliverableTarget code + parity audit per subsystem + tracked discrepancy registry - 05Phase 5
Deployment & handover
ATLAS stepsE7 DeliveryProgressive go-live with PowerBuilder ↔ target coexistence during transition (duration set at scoping based on risk profile), batched cutover, REST API exposure to cloud workflows and third-party integrations, ops handover to client team with documentation and pair-programming.
Phase deliverableTarget application in production + exposed APIs + autonomous client team + maintenance plan
At the core of the ATLAS method
AI to understand PowerBuilder, not to translate it.
PowerBuilder's DataWindow has no equivalent in target platforms: a single object combining SQL query, layout, validation rules and update behaviour. Conversion tools reproduce it as generic grids, losing the validation rules it carried. End-to-end automatic translation isn't a modernization method, it's a debt transfer.
Our approach is the opposite. ATLAS relies on multiple readings of the source code, from several angles. Here, what we read first: each DataWindow, to separately extract its query, validation rules and persistence behaviour, plus PBL libraries and their cross-dependencies. AI comes in as a comprehension accelerator, to decipher years of accumulated business logic, reverse-document uncommented branches, surface the intent behind the code. It doesn't decide and it doesn't translate. It informs the architect's work, who then designs the target architecture and drives the migration pattern by pattern, under parity audit.
This understanding still requires humans who know the source technologies. That's our edge: where Europe and North America face a retirement wave on these skills, Tunisia retains experienced PowerBuilder and PowerScript developers, paired with modern architects. Together they ensure continuity between the original business intent and the target system.
Who is concerned
Business context and modernization stakes.
PowerBuilder: legacy surviving in finance and sectoral ERPs
PowerBuilder (Sybase then Appeon) remains present in SMEs and mid-caps, regional banks, mutualist insurers, and sectoral ERPs developed between 1995 and 2010. Its historical strength: the DataWindow, a component that combined data model, presentation, and interactivity in a single object — extremely productive for transactional business applications. Its weakness today: inactive vendor, rare expertise, client-server architecture incompatible with mobile and web. Modernization is no longer a long-term option.
Why migrate now
Three forces drive migration. First, the gradual disappearance of PowerBuilder developers: profiles trained in the 2000s are retiring or reconverting, with no new graduates. Second, the structural incompatibility with modern channels (mobile, responsive web, API integrations) forcing costly workarounds. Third, the single-vendor fragility of Appeon PowerBuilder: any future investment depends on a single supplier's health. The ATLAS methodology frames this modernization predictably.
Access capability — transposable methodology, POC on your code on request
Access International has not yet delivered a client PowerBuilder modernization program. The capability is nonetheless real: the ATLAS methodology (10 steps, 9 principles, internal classified discrepancy registry) applies to 4GL legacy modernizations with an excellent fit — our Delphi journey demonstrates the application on a very close language (Pascal, VCL, FireDAC share PowerBuilder's RAD spirit). We propose a 2-3 week PowerBuilder diagnostic on your real code before any program commitment, to measure effective productivity and reliably calibrate scoping.
Target technology
.NET Core 8 or Java 21 or TypeScript, PostgreSQL or SQL Server, REST API, SPA or WinForms frontend depending on context
Technology alternatives
Compare target trajectories.
.NET Core 8 + C# + SQL Server + SPA frontend or WinForms
Most frequent choice in practice: C# is syntactically close to PowerScript, Microsoft ecosystem dominant in PowerBuilder target SMEs/mid-caps, Appeon PowerServer offers assisted transition. WinForms if desktop need preserved.
Java 21 + Spring Boot + PostgreSQL + SPA frontend
When the target IT is Java-dominated or multi-OS portability (Linux server) is required. PowerScript-Java syntactic distance larger than PowerScript-C#.
TypeScript + React/Angular + Node.js + PostgreSQL
When the goal is true cloud-native web modernization (mobile-first, multi-channel, opening to cloud and AI workflows). See patterns in Delphi to TypeScript.
Appeon PowerServer (assisted transition)
Temporary step to expose PowerBuilder in web and REST without complete rewrite. Useful to gain time before a full migration program, not as final target (PowerBuilder debt preserved).
Scoping reference
Typical duration and team for this path.
A PowerBuilder migration is planned as a sequence of functional batches, with the cadence set at scoping based on the volume of DataWindows and the chosen target (.NET, TypeScript, Java). Typical cell: PowerBuilder-target architect, target language tech lead, target developers, a senior PowerBuilder developer for business knowledge (essential early in the program), a UX designer for web ergonomic redesign, a QA, a DBA. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured. DataWindow UI effort typically represents 30 to 50% of total effort — to be included in initial scoping, not discovered mid-program.
Challenges
- Transforming DataWindows (key component combining SQL + UI + validation + derived calculations) to their modern equivalents without breaking business consistency.
- Porting PowerScript logic to the target language (.NET, Java, TypeScript) while preserving behaviors and object lifecycle.
- Choosing the target interface: web SPA (React, Angular), WinForms .NET if desktop preserved, or mixed architecture per screen.
- Modernizing historical databases (SQL Anywhere, Sybase ASE, Oracle) to managed PostgreSQL or cloud SQL Server.
ATLAS approach
- Exhaustive PowerBuilder estate capture: screens, DataWindow (source SQL, calculated columns, validation rules, events), DataStores, PBL packages, PowerScript scripts, database integrations.
- Upstream characterization test suite on the legacy: representative datasets, entry/consultation scenarios, derived calculation validation.
- Documented pattern-by-pattern migration: DataWindow → AG Grid + web Form (TypeScript), Telerik Grid in .NET, or JavaFX TableView in Java. PowerScript → C# / Java / TypeScript with explicit mapping. PBL → target packages.
- Parallel runs PowerBuilder / target with signed parity audit, systematic business-logic exposure as REST API to open to cloud workflows (Azure Logic Apps, n8n, Power Automate, AI agents).
Expected outcomes
- Target application compliant with modern standards: dependency injection, unit tests, observability, containerization.
- Automated regression test suite, reusable for future evolutions.
- Documentation of migrated DataWindow patterns delivered with internal classified discrepancy registry.
- Business data and logic exposed as REST APIs, consumable by cloud workflows and AI agents — the client-server application becomes a composable service.
Identified pitfalls and ATLAS response
What we learned on this migration path.
Pitfall 01
Underestimating the complexity of DataWindows. A DataWindow combines SQL, presentation, validation, derived calculations — naive migration often breaks consistency.
ATLAS response
Exhaustive DataWindow mapping from Intake: source SQL, calculated columns, validation rules, onChange/onBlur events. Each DataWindow is ported to its modern equivalent (AG Grid + web Form, Telerik Grid in .NET, JavaFX TableView in Java) with per-component validation. Line-by-line parity tests on production datasets.
Pitfall 02
Migrating one PowerScript at a time without rethinking the architecture. The result is a Java/C#/TypeScript that inherits PowerBuilder debt.
ATLAS response
Bounded context business decomposition during the target architecture phase. Related PowerScripts are grouped into coherent services, shared DataStores become entities/repositories. This structural refactoring is separated from functional parity — distinct phase after cutover.
Pitfall 03
Choosing WinForms .NET by default without re-evaluating the desktop need. For most PowerBuilder applications, the original desktop need (Windows integration, offline mode) is no longer structural.
ATLAS response
Systematic re-evaluation of desktop vs web need in phase E4 Target architecture. If true modernization is desired, separate SPA frontend (React, Angular) with .NET/Java backend. WinForms only if proven desktop need and Microsoft ecosystem.
Pitfall 04
Migrating code-for-code without rethinking business-logic exposure. This misses the opportunity to transform the client-server application into services consumable by cloud workflows, AI agents, or third-party integrations.
ATLAS response
REST-API-oriented target architecture from phase E4: business logic exposed as documented endpoints (OpenAPI), with standard authentication (OAuth2, JWT), versioning, observability. The UI consumes the API like any other client — cloud workflow, n8n, Power Automate, AI agent. This is what justifies the migration beyond mere technical debt.
Pitfall 05
Declaring the migration complete after code conversion, without validating real user workflows or functional parity on the client's datasets.
ATLAS response
Principle E7 — browser and business workflow validation mandatory before delivery. Parallel runs PowerBuilder / target on key transactions, automated comparison of results, parity audit with an internal classified discrepancy registry following a CRITICAL / ADAPTATION / COSMETIC grid. No cutover without proven parity.
Cell composition
A specialized cell for this modernization path.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Duration
Set at scoping based on DataWindow volume and target interface
Volume
Determined after the POC and scoping
Profiles
Target language Tech Lead
C# (.NET Core), Java (Spring Boot), or TypeScript (Node.js), PowerScript→target translation patterns, line-by-line traceability
Target developers
Ideally with client-server background (Delphi, VB.NET, C#) to understand the PowerBuilder object model; target training if needed
Senior PowerBuilder developer
Accumulated business knowledge, legacy code reading, resolving interpretation ambiguities early in the program (essential)
UX designer & frontend
Web ergonomic redesign (React, Angular), responsive, accessibility — only if web target (not required for WinForms)
DBA & data migration
Migration of SQL Anywhere, Sybase ASE, Oracle databases to cloud PostgreSQL or SQL Server, data parity audit
QA & functional parity
Characterization test bench, legacy/target comparison, ATLAS audit validation
Frequently asked questions
What decision-makers ask about this path.
Which target language to migrate PowerBuilder?+
Three main options. .NET Core: natural choice if Microsoft ecosystem dominant, C# syntax close to PowerScript. TypeScript + React/Angular: modern web target, mobile opening, see Delphi to TypeScript for patterns. Java + Spring Boot: if Java IT dominant. PowerBuilder to .NET remains the most frequent in practice, notably via Appeon PowerServer which offers an assisted transition.
How much does a PowerBuilder migration cost?+
Cost depends on three variables measured at scoping: the number of DataWindows and their complexity (a DataWindow carries SQL, layout and validation rules at once), the volume of business logic in PowerScript scripts, and the target choice between web frontend and desktop. Exhaustive DataWindow mapping happens at Intake: that mapping is what we price against. Free initial scoping call, 30 minutes to 2 hours.
Has Access already delivered a PowerBuilder migration?+
No, not yet. We state it explicitly rather than presenting a capability as a realization. The ATLAS methodology applies nonetheless to 4GL legacy modernizations with excellent fit — our Delphi journey demonstrates the application on a very close language. We propose a 2-3 week PowerBuilder diagnostic on your real code before any commitment, to measure effective productivity and reliably calibrate program scoping.
What happens to complex DataWindows (sub-DataWindows, dynamic computed columns)?+
Each DataWindow is analyzed individually in Discovery phase to identify real complexity. Simple DataWindows (tabular display, basic validation) migrate to AG Grid or Telerik in a few hours per screen. Complex DataWindows (nested sub-DataWindows, dynamic computed columns, cascading onChange events) require deep analysis to identify equivalent patterns (nested components, reactive formulas on the frontend, API hooks). Average effort per DataWindow varies from 0.5 to 5 person-days depending on complexity — that is why exhaustive E2 phase mapping is non-negotiable.
Is Appeon PowerServer a solution or a step?+
A useful step, not a final solution. Appeon PowerServer allows exposing an existing PowerBuilder application in web (.NET or JavaScript) without complete rewrite, encapsulating DataWindows. Pros: fast modernization, PowerScript business code preservation, lower initial investment. Cons: single-vendor dependency, PowerBuilder debt preserved, Appeon license costs, evolution limits. Our position: Appeon PowerServer is useful as a temporary step to quickly expose web during a full migration program to .NET / Java / TypeScript — not as final target.
How does ATLAS guarantee functional parity on PowerBuilder?+
Four combined disciplines. (1) Exhaustive DataWindow mapping from E2 Discovery (source SQL, calculated columns, validation rules, events). (2) Upstream characterization tests on the PowerBuilder legacy: the suite characterizes behavior before any target code is touched. (3) Parallel runs PowerBuilder / target on client datasets with automated comparison — target > 99% equivalence on critical paths. (4) Signed discrepancy registry by program committee: each gap documented, weighted, arbitrated, and contractually signed. See the full ATLAS methodology.
Considering a PowerBuilder modernization?
Three concrete ways to start — from a short diagnostic to a full program. Access has not yet delivered a client PowerBuilder migration: we state it explicitly and propose a 2-3 week diagnostic on your code before any program commitment.
Case studies
Client cases on this technology
Public sector — North America
IT modernization and digital transformation for a North American public sector organization
View case study →
Multi-sector
Legacy migration POC (COBOL, Delphi, BizTalk, mainframe)
View case study →
Access capability — internal POC
CapabilityDelphi → .NET Core 8 capability validated on internal POC
View case study →
Other paths in the same pillar