WinDev to web migration: when to leave WinDev, and which path to take

You should migrate a WinDev application to the web when it holds the business back: people need it away from the office or on a phone, customers and partners need to connect to it, a single developer holds all the knowledge, or the Windows machines it runs on can no longer be updated. There are three realistic paths: move to WEBDEV with the same vendor, rewrite in C# and .NET, or build a web application on open standards. In every case, moving the HFSQL data and recovering the business rules weigh more than the choice of language.

This guide is for the person who has to decide, not for the developer who will write the code. It does not run WinDev down: the tool has given many small and mid-sized companies, especially in France, business software at a low cost, and many of those applications run perfectly well. The question is whether yours needs to change, and how to change it without stopping the company.

What WinDev is, for readers outside France

WinDev is a development environment for Windows applications, published by the French company PC SOFT. It comes with its own programming language, WLanguage, and its own database, HFSQL (formerly HyperFileSQL). Sister products cover the web (WEBDEV) and mobile (WINDEV Mobile). Its integrated, all-in-one design is its strength at the start, and becomes a constraint as the company grows.

If you are an international group that inherited a WinDev application with a French acquisition or subsidiary, everything below applies.

Why so many companies want out

The reasons that come up most often:

• Access outside the office: sales reps, field technicians, branches and remote staff who need the software without a Windows PC on the company network;
• Opening up to customers and partners: an ordering portal, case tracking, an automatic exchange with a supplier or a marketplace;
• Dependence on one person: the developer who wrote the application, in-house or freelance, retires or moves on, and the knowledge goes with them;
• Dependence on one vendor: licences, version upgrades and technical choices all go through PC SOFT;
• Ageing workstations: Microsoft ended support for Windows 10 on 14 October 2025. An application installed on old machines inherits their security holes.

When it is better not to migrate

A migration is expensive and ties up your team. It is not justified if your application:

• works and changes rarely;
• runs on supported workstations and an up-to-date server;
• is maintained by a competent, available developer, with the source code under your control;
• needs neither remote access nor connections to the outside world.

In that case, secure what you have: verified backups, documentation of the main business rules, a WinDev version upgrade if needed, and a second developer who knows the project. Keep the migration for the day a real need justifies it.

The options compared

One more technical option exists: remote-display tools that publish a Windows application in a browser without rewriting it. They solve access, not dependency, and the interface stays a desktop interface on a phone screen. Treat them as a bridge, not a destination.

Moving to WEBDEV

It looks like the shortest route. PC SOFT's WEBDEV page (checked on 7 November 2026, French version) states that WINDEV, WEBDEV and WINDEV Mobile share classes, procedures, reports and queries, and that HFSQL ships as standard. The same page states that deploying sites requires the WEBDEV Application Server, under a separate licence.

What that means for you: part of the business logic carries over, but the interface has to be redesigned, because a web page does not behave like a Windows window (navigation, sessions, network latency). And you stay in the same ecosystem, with the same dependencies. It is a good option if your problem is remote access, not vendor dependence.

Rewriting in C# and .NET

This is the "WinDev to C#" route: leaving WLanguage for a mainstream language widely used in business, on Microsoft's .NET platform. You can keep a Windows desktop application if your users need one, or move to the web with ASP.NET Core.

There is no converter that cleanly turns a complete WinDev application into C#. Translation helpers exist, but their output has to be reviewed and restructured. In practice, it is a rewrite guided by the existing application. .NET makes most sense if your IT is already built around Microsoft (SQL Server, Active Directory, Microsoft 365) or if you have C# developers.

Building a web application on open standards

An application in the browser, a PostgreSQL database, documented APIs. This path opens the most doors: access from any computer, tablet or phone, a customer portal, automatic exchanges with other software, hosting wherever you choose. It is also the path that requires rethinking the most: printing, barcode scanners, scales, offline use. Our guide to the tech stack for business software helps with the technology choice.

The real project: the HFSQL data

Whatever the path, the data has to move into the new database. HFSQL comes in two modes: Classic, where each table is a set of files on a shared drive (data, indexes, memos), and Client/Server, where a server manages the database. The second lends itself better to a gradual migration, because access goes through a server instead of a shared folder, which suits an old and a new program working on the same data.

Three ways to extract the data, depending on your version and volume:

• an export from the application itself or from the HFSQL administration tools supplied by PC SOFT, to text or XML files;
• the ODBC driver distributed by PC SOFT, which lets other software read the tables (check availability for your HFSQL version);
• a small WinDev extraction program, written by a developer who knows the tool, when the first two are not enough.

The classic traps in an HFSQL migration:

• undeclared integrity: relationships between tables are often enforced in the code, not the database, and orphaned records have built up;
• memos and attached files, stored separately and sometimes large;
• dates and numbers typed into text fields, in formats that changed over the years;
• character encoding, when the application moved from an old version to a recent one;
• calculated fields where nobody remembers whether the stored value or the recalculated one is authoritative.

The full method, including trial migrations and business sign-off, is in our guide to legacy data migration.

Other risks to plan for

• Business rules buried in WLanguage: pricing, discounts, due dates, input checks. You recover them by reading the code, when you have it, and by watching users work.
• Printed reports: delivery notes, invoices, labels. There are usually many, and each has to be rebuilt, as PDF or for the specific printer.
• Devices: barcode scanners, scales, label printers, card readers. Each needs a browser-based solution or a small local relay.
• Offline use: a workshop or warehouse with poor coverage needs a degraded mode.
• Source code: check that you have it, up to date, and that you are allowed to use it. Our article on who owns custom software source code sets out the rules, with rights defined case by case in the contract.

Migrate in steps, not in one go

A central WinDev application is a poor candidate for a single cut-over: everything happens on one day, and the smallest omission stops the whole company. The safer method is to build the new application alongside the old one, module by module, an approach often called the strangler pattern:

1. Inventory: the windows and reports actually used, by whom, and how often. In an old application, part of it is no longer used at all.
2. A first module chosen for its value: usually what the current application lacks most, such as mobile access for technicians or a customer portal.
3. A prototype validated by users before any development.
4. Coexistence: the new module reads the HFSQL database, ideally in Client/Server mode, or receives its data through a regular exchange.
5. Module-by-module cut-over, with a rollback plan, until the WinDev application is switched off.

The same logic applies to Access databases, and the broader method is described in our guide to legacy application modernization.

What a WinDev migration costs

Cost depends on the same factors as any modernization: the number of windows really in use, business rules, printed reports, integrations, and the volume and state of the data. The source language matters little. What really makes a WinDev migration heavier is a large number of reports, hardware devices and missing documentation. The cost items are broken down in the cost of software modernization.

The decision-maker's checklist

• Do you have the current source code, and the latest version of the environment that opens it?
• Is the database HFSQL Classic or Client/Server?
• Which windows and reports are used every week?
• Which devices and printouts are indispensable?
• Who in the team knows the business rules and can validate them?
• What need justifies the migration: mobility, openness, dependence, security?
• Where will the new application be hosted, and under which jurisdiction?

Where to start

Gather a few screenshots of the most-used screens, the list of printed reports and, if possible, an export of the database. With that, one conversation is enough to tell which path suits you.

At LPR Studio, that conversation leads to a free visual prototype of the first web module, presented by video call within 5 working days: your team sees its future screen before any decision is made.