So let me give a scenario.
You spin and start up 3 strapi instances at the same time.
All of them will try do a database change (Let’s say you changed author to be a number field instead of blocks)
First one starts, (due timing) does the change, then few seconds later the next one does it’s check and does the same change etc. Hence why I think you have the issue.
I was working for a big company before and had a similar issue as we had Multiple Strapi instances connected to 2-3 databases for redundancy.
What I came up with as a good idea is to have a “ops” instance, so ALL strapi instances have migration set to false.
Except for the “OPS” instance. So when doing migration or database changes, you deploy OPS so migration happens, then you roll out the other instances.
This then should ensure that only 1 instance tries to do database modifications at one time and might prevent the issues you are seen.