u/EchidnaFlowers

To be honest, it's the things that only exist in people's heads.

If you work with SQL Server, MySQL, and Postgres, each engine has its own quirks that aren't obvious until you've been burned by them once. Why a query was written a certain way, why an index exists, or why somebody added a workaround three years ago are exactly the kinds of things that never make it into documentation.

Does your documentation actually stay up to date, or does it only get updated after a new team member starts asking questions?

Had this happen after a migration.

Script ran clean. No errors. Everyone moved on.

A couple days later someone notices numbers don’t match, or a column suddenly has way more NULLs than it should.

Nothing “failed”. The script just did exactly what it was told.

Seen a few patterns:

• strings getting silently cut because the target column was smaller
• filters dropping more rows than expected
• mappings assuming data is always there when it isn’t
• constraints turned off “just for the migration” and never turned back on

None of that throws an error. You only see it when someone actually uses the data.

We started treating validation as a separate step. Row counts, quick spot checks, anything that shows “this doesn’t look right”.

Sometimes even just comparing source vs target catches things early (used dbForge Data Compare for that a couple times, mostly to avoid rewriting the same checks).

“no errors” just means it didn’t crash.

had cases where everything looked fine and then turned out wrong later?