Modernization
Desktop and client-server systems: to the web without stopping operations
Visual Basic 6, PowerBuilder, Delphi, Oracle Forms, Access or FoxPro: systems that still support critical processes but are harder every year to install, maintain and connect. We take them to a web application, module by module.
The problem
It works, but it gets more fragile every year
Some of these tools no longer have vendor support, and others depend on specific Windows versions or on licenses that make every upgrade more expensive. Few people are left who know how to change them, and business logic usually lives mixed into the screens or in stored procedures. Rewriting everything at once is the risk nobody wants to take.
How we do it
From the desktop screen to the web
Inventory of screens and rules
Every form, report and stored procedure is inventoried and linked to the tables it touches.
Logic separated from the screen
Rules that live today in button events or form code are extracted into a verifiable specification.
Same database at the start
The new system can start on the current database, so both coexist while modules switch over one by one.
Parity before switch-over
Each module is compared against the desktop system with rule-level tests before users move.
Illustrative scenario
A distributor running its system on Visual Basic 6 and SQL Server
Imagine an order, inventory and billing system built in Visual Basic 6, installed on every workstation and connected to SQL Server.
- The measured sample takes a few order screens and turns them into a specification with tests.
- The diagnostic orders the modules in waves: first queries and reports, then order entry, and billing last.
- The web version of each module coexists with the desktop one on the same database until its parity is signed.
- When the last module switches over, the installer is removed from the workstations.
Illustrative scenario: A hypothetical example to explain the method: it does not describe a client or a measured result.
What you keep
A web application your team can maintain
Code in current technologies, a specification and rule-level tests. Even if you don't continue with the migration, you keep your system's specification.
Frequently asked questions
Do my users have to learn everything again?
Not necessarily. The workflow and data-entry order they already know can be kept; interface changes are agreed module by module.
Does the database have to be migrated at the same time?
No. Usually it is kept at the start and you decide later whether to change engines. See database migration.
Do you have your own case with these technologies?
Our documented own case is a migration from GeneXus. The method starts from the system's schema and behavior, not from the language; the measured sample is how you check it on yours before committing.
Next step
Start with a measured sample: 5 to 10 screens of your system turned into a verifiable specification, with tests and an inventory of differences.