An application written decades ago in Visual Basic 6, FoxPro, Delphi, or COBOL is still working, and that's why no one touches it. The risk is not the language: it's that the rules of your business live within it, that perhaps no one has them written down, and that the team that built it is no longer around.
An application written decades ago in Visual Basic 6, FoxPro, Delphi, or COBOL is still running, and that's why no one touches it. The risk isn't the language: it's that your business rules live inside it, perhaps no one has them written down, and the team that built it is no longer around. This page explains how to address it, whatever the language.
To get started, simply describe what the application does. Do not send credentials or databases.
Request your Proportione Legacy diagnosis
Each language has its own section with its own questions:
An application of this type mixes four things: the data, the screens you work with, the reports, and the rules that decide what happens in each case (how it's calculated, what's validated, who can do what). The language is just the wrapper for the four. Changing it without knowing what rules it contains is the most common way for something to stop working without anyone noticing until late.
That's why the first question isn't 'What language do I migrate it to?', but 'What does it actually do?'. We start with a diagnosis of its data and processes before choosing a destination. It delivers an inventory of processes and data, the options (build, buy, or connect), and a phased scope proposal.
End-of-support dates are those published by each manufacturer, not ours:
What it means for you: an application without manufacturer support does not stop working from one day to the next, but every change in the surrounding system leaves it more isolated. Next step: choose the section below that resembles your case.
A Visual Basic 6 application is usually a Windows desktop application: forms, reports, a database behind it, and third-party components installed on each computer. Migrating it means deciding what to do with each piece, not translating line by line.
1. A web application. It is used from the browser, without installing anything on each computer. 2. A modern desktop application. When the work requires being on the computer, for example, due to a connected device. 3. Connecting it. The application remains as is and is accessed via APIs and connectors so that the rest of your systems can use it.
The diagnosis compares the three with the data from your case. There is no better destination in the abstract.
We start by seeing what's there: executable, data, documentation, people using it. Until you look, you don't know what can be recovered and what cannot. Extraction is only done with the system owner's authorization, and what cannot be recovered is stated in writing before proceeding.
No. It is delivered in phases, with acceptance criteria and a rollback plan, so that each step can be checked and, if necessary, undone. How the change of each phase is organized is defined in the proposal.
They will be inventoried. For each one, it is decided separately whether to keep it, replace it, or remove it, and this is put in writing in the scope proposal.
FoxPro and Delphi often appear in custom management applications made many years ago: a proprietary database, forms for data entry and queries, reports. The question almost everyone asks is the same: do I redo it or leave it as is?
The answer does not depend on the language, but on what the application does for you today and what you need it to do tomorrow. We describe the method, which is the same for any language.
Opening it with APIs and connectors allows other systems to read and write to it without redoing it.
In that case, it is rewritten in phases: first the pieces that weigh the most, with acceptance criteria set in advance.
What it means for you: rewriting and connecting are not mutually exclusive: you can connect today what works and rewrite tomorrow what does not. Next step: request a diagnosis, which compares the options with your data.
The data would be inventoried before deciding anything: what tables exist, which ones are used, and in what state they are. It is decided what is moved to the destination, what is archived, and what is retired, and it is checked afterwards.
It depends on the version you have installed and the manufacturer's policy. We don't give a date: what we do in the diagnosis is note which version and components your application is built with.
It depends on how it's made. Sometimes it can be accessed through the database or exchange files; other times, a new layer needs to be added. The diagnosis clarifies this before committing to any work.
A COBOL system is usually a management system that has been doing the same thing for decades: batch processes, master files, calculations that no one has reviewed again and that support a part of the operation. What weighs most in these systems is not the language, but knowing what is inside.
The useful question is what is preserved. What is preserved and what is not is decided piece by piece:
The extraction of rules and data is always done with the authorization of the system owner. If there is no documentation, the inventory is the first deliverable of the diagnosis.
What it means for you: you know what rules and what data you have, and what is kept of each, before committing to a change. Next step: describe the case for us in the form.
Both are options. If the system does its job well, connecting it with APIs and connectors is usually the first to consider. If every change is a risky operation, it is replaced with pieces. The diagnosis compares both with your case.
Acceptance criteria are set in advance, based on the inventoried rules: the results of the new application are compared with those of the old one on the same cases. What is decided to change is put in writing.
Whatever the language, the method is the same. General details are in how we work.
1. Diagnosis: inventory of processes and data, business rules, options (build, buy, or connect) and phased scope proposal. 2. Scoped pilot, with pre-established acceptance criteria before proceeding, when the case requires it. 3. Phased delivery, with acceptance criteria and a rollback plan. 4. Handover: verifiable documentation, export, and custody. The code is yours, and that is stated in the contract.
What it means for you: at all times you know what has been delivered, what is missing, and how to roll back. Next step: request the diagnosis.
The order is always the same: first the process is digitized and understood; then the old software is opened with APIs and connectors to link it with the rest, and only then is AI applied on top. We propose AI afterwards, when the process is understood and the data is organized.
AI can run on your own server and, if necessary, offline. This is the same option we described in legacy systems migration service and in artificial intelligence in business.
If you are looking for a new custom application and not the migration of an existing one, see custom software development. If your application is just one of several old pieces, see the whole in Business Management Consulting and our services.
If you have Excel macros or an Access application, they have their own page Access application migration. If it is a web application in PHP or on an unsupported framework, your case is in migrate PHP 5 to PHP 8 or exit an unsupported framework.
What it means for you: your data does not have to leave your premises. Next step: request the diagnosis.
With a diagnosis of your data and processes, before choosing a destination. It delivers an inventory of processes and data, the options (build, buy, or connect), and a phased scope proposal.
Not necessarily. One of the three diagnostic options is to connect: open the application you already have using APIs and connectors to link it with the rest, without replacing it. What gets rewritten and what is kept is decided piece by piece.
It depends on the scope: how many screens, reports, rules, and data there are, and what it needs to do next. That is why we do not give a figure or a deadline without knowing your specific case. The phased scope proposal, which concludes the diagnosis, is where this becomes concrete.
What is kept, what is changed, and what is retired is decided piece by piece and put in writing. Each phase is delivered with pre-established acceptance criteria and a rollback plan, allowing it to be tested and, if necessary, undone.
Yes. Data extraction, migration, and any AI used subsequently can be run on your servers or on dedicated hardware, even on an offline network.
The code belongs to the client, and this is explicitly stated in the contract. Documentation, exportability, and custody are verifiable and form part of the design.
Tell us what language your application is in and what role it plays today. We will respond within two business days. [Short form: see specification in notes] If you prefer to write to us directly: contact.
Request your Proportione Legacy diagnosisDo not send credentials or databases. We will use your data only to respond to you; more information in the Privacy Policy.
