Azure SQL Database and Azure Database Migration Service: can a small app cut over with zero downtime?

The goal is to move a small application's database to Azure SQL Database while the app keeps serving users, with no outage beyond a momentary cutover.

The documented online path pairs Azure SQL Database with Azure Database Migration Service, which copies data continuously until a final switchover. BACPAC export/import is simpler but fully offline, conflicting with the no-downtime requirement.

Two constraints make the decision non-obvious. "Online" may not mean zero downtime: large object columns can force offline phases, and the final sync still needs writes to pause briefly. Schema changes during the move, such as adding a NOT NULL column with a default, may take locks that block concurrent writes even where index operations run online. Behavior varies by service tier and changes over time, so these points warrant confirmation against current documentation.

Three open questions decide the approach:

• Does Database Migration Service support a genuinely online cutover for a small database with large object columns, or is a brief write pause unavoidable at final sync?
• For a small database, does continuous sync beat a short BACPAC-based maintenance window once setup effort and throttling are included?
• Which schema changes can be applied on Azure SQL Database without blocking writes while migration traffic runs?