Inventory and analysis
We analyse the current code: windows, DataWindows, procedures and dependencies. The result is a map of what the system really does, not what the documentation claims.
Flagship project
Your PowerBuilder application, on the web and in the cloud
We modernize client-server systems built in PowerBuilder without throwing away twenty years of business rules. In phases, with the current system running in parallel.
If this sounds familiar, it is for you
- The system your business runs on only works installed on Windows
- Finding someone who can maintain it gets harder every year
- Nobody documented the rules: they live in the code and in two people's heads
- Rewriting from scratch feels like a risk you cannot take
How we do it
Migrating without betting the business on one throw
A full rewrite in one go is the most common way to fail. We migrate in parts, and each part goes live before the next one starts.
Rescuing the business rules
The value is not the code, it is the rules inside it. They are extracted, written down and tested before anything is rebuilt.
Conversion to web architecture
Angular or Vue on the front, Java with Spring Boot on the back, with its own API. The application now opens in a browser, with nothing to install.
Data migration
From Sybase or Oracle, with no loss of information, reconciling old and new until the figures match.
Phased rollout
Module by module, with the current system running in parallel. If one phase fails, the business keeps working.
Cloud operations
Once on the web, the application lives on AWS: backups, monitoring, automated deployment and costs under control.
Who it is for
This is not for everyone
It fits well if
- You have a PowerBuilder application in production your operation depends on
- You need it to keep working while it is modernized
- You want to keep the business rules that already work, not reinvent them
It probably does not fit if
- Your application is small and rebuilding from scratch is cheaper
- You are looking for an automatic translator that converts the code unattended
- You need the whole thing finished in a few weeks
FAQ
What people usually ask us
That is the main risk, which is why analysis comes first. Rules are extracted and written as tests before rebuilding: if the new system does not produce the same result as the old one, the test fails.
It depends on size and number of modules. We do not give a number without seeing the code: the initial inventory is exactly what makes a grounded estimate possible.
We migrate with both. The current engine can be kept at first and changed later, so you are not moving two pieces at once.
Yes, and it is the recommended path. We start with the module that hurts most or depends least on the rest, and old and new coexist through the transition.
Shall we look at your current system?
The first conversation is an assessment: what you have, what hurts and which path makes sense. No strings attached.