I think ideally, a SOLID microservice architecture would imply that a service for model A doesn't care about the schema changes for model B, so migrations could live in the repo for the services they are for.
I could be wrong though, are you running into a specific problem?
Specifically, I'm using knexjs for migrations and I was unable to run migrations for files that were not present in the current service migration directory. What I mean is, KnexJS would look through its migrations folder and attempt to correlate previous migrations in the migrations table with the files present. If it doesn't find them, it throws an error. So I decided to move all the migrations to a separate service and do version control there.
I think ideally, a SOLID microservice architecture would imply that a service for model A doesn't care about the schema changes for model B, so migrations could live in the repo for the services they are for.
I could be wrong though, are you running into a specific problem?
Specifically, I'm using knexjs for migrations and I was unable to run migrations for files that were not present in the current service migration directory. What I mean is, KnexJS would look through its migrations folder and attempt to correlate previous migrations in the migrations table with the files present. If it doesn't find them, it throws an error. So I decided to move all the migrations to a separate service and do version control there.
Ah, I'm used to EntityFramework which stores it' "Last Migration" information in a table on the database, so I'm sure if that would be an issue.
Seems like a good enough reason to keep your migrations in their own repo to me.
There is also probably an argument that could be made for a monorepo for all your microservices.