How to migrate a DataFlex application to PHP and MySQL: the complete guide

This is the method we use, written down: the sequence for taking a DataFlex application, DOS screens or Visual DataFlex, to PHP and MySQL without losing a record or a day of trading. It is craft knowledge, not theory.

Step 1: audit what the system actually does

Not what the documentation says. What it does. Decades-old systems accumulate three layers: the system as designed, the system as modified, and the system as actually used. Only the third one needs migrating.

The audit walks every screen with the people who use it, lists every report anyone still reads, and maps every table against the screens that touch it. It always finds dead weight: modules for product lines sold off years ago, reports nobody has printed since the contact who wanted them left. Migrating less is cheaper than migrating everything, and the audit is where you find out which is which.

Two questions matter more than any other at this stage. What goes into the system, and what must come out of it. Everything between is implementation.

Step 2: extract the data

DataFlex stores its tables in proprietary .DAT files. DOS-era systems use fixed-length records with typed fields, defined by the table specifications the system itself carries. Old does not mean chaotic: these formats are rigid and consistent, which is good news for extraction.

The practical gotchas, from the bench:

• Code pages. DOS-era data is stored in OEM code pages, not Unicode. Read it naively and every pound sign and accented name in decades of records comes out wrong. Conversion has to be explicit and checked.
• Dates. Legacy date fields arrive in formats designed for storage efficiency, not clarity, and two-digit years appear exactly where you would dread them. Every date column needs a declared interpretation rule, tested against records whose true dates someone can vouch for.
• Overloaded fields. Decades of users will have pressed every field into second jobs: a notes column that secretly drives a workflow, a spare numeric repurposed in 1998. The audit interviews catch most of these; reconciliation catches the rest.
• Record numbers. DataFlex applications lean on record numbers as de facto keys. The new schema gets proper keys, but the old numbers are preserved in an archive column so any historical reference can still be traced.

Extraction is scripted and repeatable, never a one-off manual export. It will run dozens of times before cutover, and the final run has to be boring.

Step 3: design the schema, do not copy it

The old structure encodes the limits of 1980s hardware: cryptic eight-character names, fields sized to save bytes, relationships enforced by convention because nothing else would enforce them. Copying that into MySQL would preserve the constraints without the excuse.

The new schema gets real names, correct types, foreign keys that actually enforce the relationships the old system maintained by discipline, and indexes designed for how the business queries today. Alongside it sits an untouched archive of the raw extracted data, so there is always a path back from any migrated value to the bytes it came from. When someone asks, in 2031, why an invoice from 1994 says what it says, the answer is checkable.

Step 4: rebuild the behaviour, not the code

No transpiler gets you off DataFlex; the language is not the asset. The behaviour is. The rebuild ports what the system does, screen by screen and rule by rule, into a web application any PHP developer could maintain.

One craft point that surprises people: respect the keyboard. Staff who have run order entry on function keys for twenty years are fast, and a mouse-driven interface that slows them down is a regression dressed as progress. The new screens keep keyboard-first entry where speed matters. F2 to save. Now it just saves, but F2 still works.

Reports get the same treatment: the ones that survive the audit are rebuilt to produce the same numbers, provably, before anyone improves them.

Step 5: the parallel run

This is the step that makes the rest safe. The old system stays live and primary. The new system runs alongside it, fed the same reality, and every day the two are reconciled: record counts, financial totals, and spot checks on individual records chosen to be awkward.

Disagreements are found, explained and fixed while they cost nothing, because the old system is still the system of record. The parallel run ends when the comparison report has been boring for long enough that the business stops reading it. That decision belongs to the business, not the calendar.

This discipline is what lets a migration promise “every record kept” and mean it. The promise is not a slogan; it is a reconciliation report, run daily, that anyone in the business can read.

Step 6: cutover and aftercare

Cutover, done this way, is an anticlimax. The new system becomes primary, the old one stays available as a read-only fallback, and trading continues. No big-bang weekend, no prayer.

Aftercare is a monthly retainer: hosting, support and the steady stream of small improvements that a system built this decade can finally absorb. Expect the first change request within a week of cutover; it is the surest sign a new system is being used.

What it costs

The honest answer is a process, not a number on a blog. The Rescue Roadmap is £1,950 fixed: code and data audit, options compared, fixed-price proposal, credited against the build if you proceed. Before that, the free Legacy Risk Audit tells you where your system stands in 30 minutes plus a written one-pager.

The platform background, every DataFlex version and date, is on the DataFlex migration page.