Loading...
Loading...
Migration of PowerBuilder applications (client-server, DataWindow) to .NET Core, TypeScript, or Java. ATLAS methodology.
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.
.NET Core, TypeScript, Java, bases relationnelles modernes
A PowerBuilder migration is planned over **ten to twenty-four months** depending on the volume of DataWindows and the chosen target (.NET, TypeScript, Java). Typical cell: PowerBuilder-target architect, target language tech lead, two to four target developers, a senior PowerBuilder developer for business knowledge (essential), a UX designer for ergonomic redesign, a QA, a DBA. For **fifty to one hundred fifty DataWindows**, plan **ten to sixteen months** with a cell of **six to ten people**.
Underestimating the complexity of DataWindows. A DataWindow combines SQL, presentation, validation, derived calculations — naive migration often breaks consistency.
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.
Migrating one PowerScript at a time without rethinking the architecture. The result is a Java/C#/TypeScript that inherits PowerBuilder debt.
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.
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.
For a PowerBuilder application of fifty to one hundred fifty DataWindows in nearshore co-delivery, plan 800 k€ to 1.5 M€ over 12 to 18 months. Higher cost than Delphi on equivalent volumes because DataWindows are more complex to port (combine SQL + UI + validation). See the delivery models.
We frame the trajectory, the budget, and the deliverables in a first thirty-minute conversation. A short POC can be proposed before committing to the full program.
Start this path →