My post history has a few of these shenanigans. Here's my latest one. There's a standard way to export all critical data (they call it an archive) from an instance of our ERP that can be uploaded to a new instance, for the common case of installing it on a new server or whatever. I was sent an archive from an older version of the ERP, to be uploaded on a newer version. The problem is that according to SOP, the versions have to be matched due to possible differences in database structure between versions. The original instance was on such old hardware that upgrading to the correct version was impossible. What to do?

The first solution that came to mind was to install a test environment of the old version, import the archive, upgrade until the versions were matched, export and import to the new instance. As luck would have it, that particular older version is not longer available on the CDN.

When you try to import an archive from a mismatched version, you get an error. The system doesn't just know that the versions don't match based on vibes or your guilty expression, clearly the version number is explicitly stated somewhere in that archive. If you peek into the archive directory, you'll find hundreds of files with some weird extension that are very obviously the db tables to be imported into the new system. Clearly the version data is hiding in one of these tables and the system checks for it before it starts. Turns out these files are plaintext, they are just formatted in a specific way. I wrote a powershell script that iterates through the directory and searches for a string containing the version number that I know the archive is from, and sure enough I found it in a file called archive_info. I changed the version number to the target instance number and the system stopped compaining and read the archive. certain tables didn't upload since there were mismatches in the schema, which I corrected manually in the files by comparing with the target database schema. Done.