Migrate HFSQL as its own program — not an afterthought to the rewrite.
Application modernization and data modernization are connected, but they don't have to happen at the same moment. Treat the database as a controlled program with its own inventory, its own target choice and its own acceptance test, and the rewrite gets easier to trust.
Why not migrate both at once
- Every defect becomes ambiguous. Move the app and the database together, and a broken screen could be converted code, SQL semantics, data transformation, or infrastructure — you won't know which.
- The legacy system needs a floor to stand on. Convert the schema 1:1 first, and your legacy WinDev application keeps running on the same data while the rewrite proceeds.
- Reconciliation needs a stable target. You can't prove row counts and control totals match if the schema is also changing shape underneath you.
- The target database is a separate decision. PostgreSQL, SQL Server or MySQL should be chosen for what the product needs next — not for whichever mapping was easiest to automate.
What to inventory before you touch a column
- Tables, keys and constraints. The structural backbone, captured before anything gets rewritten.
- Queries embedded in screens, reports and procedures. HFSQL logic that never lived in a single, obvious place.
- Stored procedures and triggers. Server-side behavior that has to be accounted for, not just the schema.
- Blobs, filesystem assumptions and precision semantics. Attachments, character sets, dates and null handling — the details that break reconciliation later.
- Concurrency and transaction behavior. How HFSQL actually handles locking today, so the target database can be configured to match.
Choosing the target database
PostgreSQL
An open stack with strong SQL capabilities — the default when there's no reason to stay Microsoft-centered.
SQL Server
A natural fit for organizations already standardized on Microsoft infrastructure and licensing.
MySQL
Practical for widely hosted web products where the ecosystem already expects it.
The choice should come from what the product needs next, not from whichever converter has the easiest type mapping.
Reconciliation is the acceptance test
What gets checked: Row counts, key totals, control totals where they apply, orphan relationships, null and precision behavior, and the results of representative queries — against the real workload, not synthetic inserts.
How milestones cut over: Migrated application milestones keep using the established data contract while the new persistence is prepared, then a bounded domain cuts over — with your legacy still running on the same data until it doesn't need to.
Questions developers ask first
No — the schema is converted 1:1 first specifically so your legacy keeps running unchanged while the application migration proceeds on its own timeline.
You do, based on what the product needs next. WXCode doesn't push a default to simplify its own conversion.
Reconciliation against row counts, control totals and representative query results — the same checks a controlled data program uses, not a spot check.
Related guides
Test it on your real project.
Start with the knowledge base, the dependencies and the business rules — before committing to any rewrite.