I agree with Phil here on the process. BUT I would strongly suggest you do NOT make changes to production systems until you verify the changes on a test system.
So my first step would be to build up the script you are wanting to run, be it a generic ALTER TABLE or the more complex, but safer approach that Phil provided, and then test that on a test system that is a clone of each of the live systems. Then you can verify that the change fixes the problem and doesn't introduce new problems. If it does fix it without making new ones, get someone who is familiar with the data to do some data validation and if everyone is happy, then go live with it. Doing it on test also gives you a good idea of the downtime that will be required.
I would be cautious about changing to a smaller datatype. What I mean is changing from INT to BIGINT shouldn't cause any issues as ALL INTs fit inside BIGINT with room to spare. BUT if the datatype is already BIGINT and you are changing it to INT, it could fail.
Same problem can occur if you go from NVARCHAR to VARCHAR.
Now, offhand, I am not certain if it will fail due to an overflow OR if it'll succeed and set any overflow values to NULL as I've not tried it before. With the NVARCHAR to VARCHAR, you may lose some characters or have characters changed which is not desirable. But the BIGINT to INT I THINK will fail if there are any bigint values in there that don't fit in an int.
My approach would not be to switch a BIGINT to an INT, but to go the other way.
I would also be looking into that 3rd party application. If it is failing due to an INT overflow (for example), then casting your BIGINT to INT is going to fail. If the app is failing due to the NVARCHAR stuff, you will likely want to contact the app vendor to fix that bug and not change the database datatypes. I know if I was a user of a tool and the suggestion was to change from NVARCHAR to VARCHAR and they did that change without talking to me and without testing and I had all my multi-language strings come back in the English alphabet only, I'd not have very nice words for the team that made that change...
Now, I do agree that your datatypes should be consistent across the databases as otherwise you can run into slowdowns during your QA process as you should be testing on all configurations. If the datatypes are the same across all databases and tables, then the QA process is a lot easier to do. Same thing with UAT - you wouldn't need to have every database tested, you could pick a few randomly and have the sample do UAT.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.