The usual advice is that the form is corrupted so you should rebuild it but I highly doubt a corrupt form is OK in one version but not in another. I (and others) have lately been saying that when updating it is not uncommon to find that ambiguous code (a polite way of saying it's a bit sloppy) that was passable in older versions becomes a problem when a new version of a reference becomes involved. That can be the Access db engine itself, DAO or ADO, Scripting Library, VBA, Office, etc. Start by ensuring the code project compiles. If any of the modules do not have Option Explicit at the top, that is not good and can be a contributing factor. If this code project is not complete, you ought to turn on Require Variable Declaration. Regardless, you should go into every module and add that line and see if it still compiles and fix any errors that arise.
The code you see can also be different from how Access has compiled it. In that case, you open the db with the compile switch (google it) and Access 'dumps' the compiled version and rebuilds it. That should ensure that what you read is exactly as it has been compiled. My inclination is that something is wrong with the code or sql but you're not seeing it. Likely the problem exists in code behind these specific forms, or any code in a standard module that is only called by these problem forms.
It should go without saying that these things should be done to your db after you have created a backup of the latest version.
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.