Filament v3 upgrade command leaves migration sequencing undefined for zero-downtime deploys

Context

The filament:upgrade command in Filament v3 updates Composer dependencies and publishes configuration and asset files, but it does not rewrite application resource classes, custom form fields, or table components that rely on removed v2 base classes. At the same time, Filament's internal database tables (e.g., filament_users, filament_pages) must be migrated before the new panel boots, and the Vite-compiled asset bundle must match the deployed PHP code to avoid Livewire checksum failures.

Constraints

• Running migrations concurrently with live traffic risks schema mismatch errors on in-flight requests.
• Deploying new PHP code before assets are built and cached causes immediate UI breakage for users hitting updated servers.
• Rolling deployments across multiple servers create a window where some workers serve v2 code and others serve v3 code, triggering ComponentChecksumMismatchException.
• No Filament-native orchestration exists to coordinate the required sequence: Composer install, migration execution, asset build, and config cache clear.

Questions

1. What migration sequencing strategy (code-first with maintenance mode, database-first with backward-compatible code, or blue-green cutover) has been validated for small applications targeting zero downtime on Filament v3.2+?
2. How should the asset build step be integrated into the deployment pipeline to guarantee that no server serves a PHP/asset version mismatch during a rolling rollout?