Should you leave WinDev? The four questions that decide

The question comes up whenever a new IT director arrives or an outside provider is consulted. The answer rarely depends on the technology itself, and almost always on four measurable factors.

Question 1: is the version still supported?

Vendor PC SOFT publishes one major version a year and supports recent versions. An application on an unsupported version raises three problems: no more security fixes, uncertain compatibility with recent operating systems, and growing difficulty finding help.

If you are out of support, the first decision is not to migrate to another technology: it is to upgrade the version. That costs a fraction of a migration and addresses the immediate risk.

Question 2: is the application documented?

Not in the sense of a user manual: in the sense of a map of analyses, procedures, reports and dependencies that an outside developer can read to take over the project.

If it is not, that is not a reason to migrate. It is a reason to run a takeover audit, which costs a few thousand euros and is, incidentally, the prerequisite for any serious migration too. Migrating an application you do not understand is the surest way to reproduce its flaws, worse.

Question 3: does more than one person know how to evolve it?

That is the real risk, and it is independent of the language. A Java application maintained by one person carries exactly the same continuity risk as a WinDev application in the same situation.

The fact that the WinDev developer pool is shrinking makes that risk harder to address by hiring, which is a genuine argument — but it is addressed by a maintenance contract with two named contacts, not necessarily by a migration costing several hundred thousand.

Question 4: does the application still meet the need?

If the business has changed to the point where the application covers only half the cases, if users maintain parallel spreadsheets to compensate, if every requested change is refused as too complex: then the question of a rebuild becomes legitimate.

But note that this criterion is functional, not technical. It would justify a rebuild even if the application were written in the most modern technology available.

The verdict

If all four answers are good, migrating means spending a large budget for no functional return. It is a decision we have seen taken, and regretted.

If two or more answers are bad, migration deserves to be priced — module by module, with both systems in parallel, never as a single cutover.

The middle case, which is the most common

The application works but cannot integrate with the rest of the IT estate. In that case the answer is neither maintain nor migrate: it is to open it up. Exposing a REST API over the existing system lets you plug in a modern portal, a mobile app or a BI tool, for a fraction of a rewrite's cost — and without touching the business core that has worked for fifteen years.