EF Core Migrations with old and new application instances sharing one database

Goal

Run a zero-downtime rolling update of a small application that uses EF Core Migrations, where older and newer instances temporarily share the same relational database while a pending migration changes the schema.

Constraints and uncertainty

EF Core does not coordinate concurrent context.Database.Migrate() calls across multiple instances, so simultaneous startup can race or apply changes inconsistently. Additive columns and tables are usually backward compatible during the overlap, but renames or drops can break older instances immediately. The safe placement of migration execution—pre-deployment, application startup, a dedicated migration job, or a single leader instance—depends on the relational provider and database engine, and no single approach is established as universally safe for EF Core.

Questions

Where should migration execution be placed in a rolling deployment so old and new instances remain interoperable? Can Database.Migrate() be called safely at application startup when multiple instances start concurrently against one database? Which schema changes are safe to apply while old instances are still running?