u/HolidayGramarye

The log said success. The data said otherwise. Seen this more than once after migrations. The script runs, no errors, everything looks fine. Then a few days later someone notices a report looks off, or a column suddenly has NULLs where real values used to be. The script did exactly what it was told. That’s usually the problem. A script finishing successfully just means it didn’t crash. It doesn’t mean the data actually landed the way you thought it would. A lot of migrations go wrong in quieter ways. Strings get clipped because the destination column is smaller. A mapping assumes values are always present and suddenly NULLs start showing up. A filter condition drops more rows than intended. Sometimes constraints get disabled to speed things up and nobody remembers to turn them back on before the data goes live. None of that stops the script. But it absolutely changes the data. What usually helps is treating validation as its own step after the migration runs. Check row counts between source and destination. Spot-check a few values. Look at columns where NULL rates suddenly changed. Having a quick way to compare data source and destination helps here. Something like dbForge Data Compare saves writing the same validation queries every time. “It ran without errors” is really just step one. Ever had a migration finish cleanly and then realize later the data was wrong anyway once people actually started using it?