Migration · HFSQL to PostgreSQL

Leaving HFSQL for PostgreSQL: what it really takes

When a company decides to put some distance between itself and PC SOFT, the database is often the first project that comes to mind. That makes sense: data is what holds the most value, and HFSQL keeps it in a format that only PC SOFT's tools read comfortably.

The good news: copying the structure and data of an HFSQL database to PostgreSQL is the easy part. The less good news: what costs money are the details the copy does not see, and above all the WLanguage code that reads and writes that data.

Why PostgreSQL

• Your data becomes readable by everyone again: a reporting tool, a spreadsheet, a script, another piece of software, with no proprietary driver.
• Operations tooling is standard: backup, replication, monitoring, encryption, with skills available everywhere.
• No licence, and no vendor who can one day change the counting rules.
• Constraints live in the database: foreign keys, checks, strict types. Inconsistent data is refused at the door, whichever program writes it.

One thing to know before you start: leaving HFSQL does not lower your PC SOFT session bill. Since July 2026, the database type is no longer part of the count. The exposure calculator shows it.

What copies across easily

The analysis describes everything: files, items, keys, links. It translates into tables, columns, indexes and foreign keys. The data follows, read file by file. For a mid-sized application, this part is counted in days, not months.

What bites

These are the gaps we find from one HFSQL database to the next. None of them is rare.

Empty values

By default, an HFSQL item does not handle NULL: a missing date is an empty string, a missing amount is zero. PostgreSQL tells the two apart. You have to decide, item by item, whether zero means "zero" or "not filled in". Getting it wrong skews your averages and statistics without anything crashing.

Dates

HFSQL accepts dates that PostgreSQL refuses: a 31st of February, a zero month, a two-digit year typed in twenty years ago. The migration finds every one of them. They can be fixed, but with you, not silently.

Keys that ignore case and accents

An HFSQL key can ignore case, accents or punctuation. A search for "Ecole" then finds "ÉCOLE". In PostgreSQL this behaviour can be rebuilt (collation, expression indexes), but it does not come by itself. Forgotten, it gives searches that no longer find anything, and duplicates that the unique key let through and that the new database refuses.

Encoding

A database that has lived fifteen years often mixes ANSI and Unicode items, and characters typed from workstations configured differently. PostgreSQL works in UTF-8: every badly encoded character must be identified before the migration.

Links never enforced

The links in the analysis are often described without being enforced as integrity checks. The result: invoice lines whose invoice no longer exists, customers attached to a deleted salesperson. A PostgreSQL foreign key refuses them. They have to be found, counted, and their fate decided with you.

Automatic identifiers and memos

Automatic identifiers become identity columns, migrated with their values so no link breaks, then realigned. Text memos become text, binary memos become binary columns or files, depending on their size and use. The currency type becomes an exact NUMERIC, never a floating-point number.

The real work: the code

A WinDev application does not read its database in SQL. It walks through it with the H functions: reads by key, filters, positions, current record, locks. That way of working has no direct SQL equivalent, and it carries a good share of your business rules.

It is technically possible to keep the WinDev application and plug it into PostgreSQL through a PC SOFT native access. We do not offer it. The dependency on PC SOFT stays whole, and behaviour changes in corners nobody tests: an empty value turned NULL, a sort that no longer follows accents, a lock that is no longer set the same way.

For us, the data migration is a milestone of the rewrite, not a standalone project. It goes into a properly designed database, not into a carbon copy of the original analysis, defects included.

How we run the data migration

• a replayable migration script: we run it as many times as needed, on a fresh copy of your database, until the switchover;
• evidence at every run: counts per table, checksums, samples compared row by row;
• the list of defects found: orphans, duplicates, impossible dates, badly encoded characters, each one counted and settled with you, never fixed silently;
• a rehearsal of the switchover before the real one, with a tested rollback.

Where to start

Measure before pricing. The online estimate counts your data files, windows and queries from your project, in your browser, without sending anything. The flash diagnostic goes further: from the code and the SQL script of the analysis, it tells you what locks the exit, HFSQL included, in five business days.