The first kind shouts: the compiler refuses, a command no longer exists, a plugin will not load. Annoying, but you know immediately where you stand. This work can be counted and budgeted.

The second kind turns up during testing: a window that looks different, a list that no longer sorts the way it did, an import that stops halfway. You will find these too, as long as you actually test.

The third kind raises no error at all. The application runs, your people carry on working, and weeks later somebody notices that a total is wrong. That is the kind migrations owe their reputation to.

1. Number and date formatting

Formatting depends on more than your code: on the machine settings, on the user's regional settings, and on how your version of 4D interprets them. Change any one of those three and the result changes — without anything going technically wrong.

Where it hurts: amounts assembled as text for an invoice, dates sent as strings to an external system, numbers read out of an import file. A full stop that becomes a comma, or a day and month that swap places, raises no error. It produces a different figure.

To check: every place where a number or date is converted to text or back — exports, imports, reporting and links to other systems.

2. Sending mail

The way 4D sends mail has changed considerably over the years. Older code often uses an approach that no longer exists, or behaves differently, in recent versions. The awkward part: mail that fails to leave does not always raise an error inside your application. The code carries on, the user sees a confirmation, and the message simply never arrives.

This is doubly dangerous because it usually involves messages nobody misses until it is too late: an automatic confirmation to a customer, a report that goes out overnight, a warning when something fails.

To check: every place your application sends mail itself, and whether anything actually inspects the result.

3. Printing and reporting

Printing leans on the printer definition, on the fonts installed on the machine, and on how your version of 4D lays out the page. After a migration — often alongside a new operating system or new hardware — at least one of those three is different.

The result is rarely an error. It is a column that falls just outside the printable area, a font silently substituted for another, or a report showing one line more per page — putting a total in the wrong place.

How you do catch them

The only reliable method is comparison. Put the old and the new version side by side on the same data, have both perform the same sequence of operations, and compare the output line by line.

• Use a copy of your real data, not a test set. Silent faults live precisely in the exceptions test data does not contain.
• Export the same lists, invoices and reports from both versions to text, and compare those files automatically. Your eyes skip differences; a comparison does not.
• Do it on a machine with the same regional settings as your users have.
• Test mail against a real mailbox somebody reads.

Why this matters so much

A migration is rarely judged on the commands that disappeared. It is judged the moment somebody sees an invoice go out with the wrong amount. That is usually not a large technical problem — it is a detail nobody checked, because there was never an error to point at it.

This comparison work is exactly what a migration audit does systematically: finding where your application quietly changes behaviour, before your customers do.