How to verify an HFSQL migration
A migration that "ran without errors" is not a migration you can trust. This checklist turns it into one you can defend.
Last reviewed: November 2, 2026
1. Compare row counts per table
The simplest and most important check: for every table, rows in the source equal rows in the target. Fic2All's report shows rows read versus rows written for each table, so you do not have to count by hand.
2. Read the rejects
If some rows could not be written, find out why before going further. Fic2All lists each rejected row with its column and the database error. Typical causes are values that do not fit the target column; fix the data or the target, then rerun.
3. Check text and memo fields
Open records that contain accents, special characters and long memo text, and compare them with the source. This is where encoding problems show up first.
4. Check dates, times and numbers
Compare a sample of dates, times and decimal values against the source, including edge cases such as empty dates and very large or very small numbers.
5. Check empty values
Decide how empty values should be treated in the target (empty string, zero, null) and verify that records behave as your application expects.
6. Run real queries
Run the queries your application depends on, on the new database, and compare the results with the old system. Counts match is the first check; the business answers matching is the real one.
Ready to move your HFSQL data?
Pick a plan, install Fic2All and let the verification report do the checking.
See plans and pricing