First thing I would check is to take the machines that have 2010 and open up a code window so you can open Tools>>References. Make a list of what is checked and in what order they appear.
Next, check the 2016 machine the same way. If you see any reference that claims "Broken Reference" then you have a BIG difference right there. If there is a difference in the order of appearance of references, you have found at least one more potential source of trouble, since when there are conflicting names (i.e. two DLLs use the same name for something), the order of appearance in the reference list determines which one "wins" unless you go back and qualify the object-name references. The ADO and DAO libraries were notorious for this because of the entry-point names they had in common with each other.
Another issue comes to mind. I believe I am right in this - that for Ac2010, the default Office install was the 32-bit version, but for 2013 and later it is the 64-bit version, which has different .DLL files. You will need to determine which version (32/64) you are running on the 2016 system.
To find 32/64 bit version info, open your 2016 FE in a mode where you don't launch your default form. You need the ribbon for this. Now do File>>Account then in the center of the screen, click the About Access button that has a question-mark in it. The "About" box will open up telling you the Access version, Office version, and 32 or 64-bit variant.
For S&G, do the same on a 2010 machine. If your 2010 and 2016 systems have different sizing variants, they will be incompatible without a LOT of work. In fact, at least for 2013 I have found cases where using the 64-bit variant would not be practical because the "right" DLL file doesn't exist for that variant. To make it work I would have to rebuild all external DLL interfaces (assuming I can find them) to assure that the "pointer-safe" adjustments were made. But for implicit functions, I might not have access to the calls in a way to assure that the pointer-safe adjustments are done properly.
Now it IS possible that someone installed the 64-bit version of Office for 2010, but that wasn't so common a choice six years ago.
In any case, your problem could easily be references caused by differences between the default order of libraries or implicit in the differences between data-size variant cases. If I am correct, your solution is to remove the 64-bit version and install the 32-bit version. NOTE that if you use SharePoint for the new version, you might be stuck because I don't think SharePoint works correctly with the 32-bit version.