Migration Guide
Migrating from Vercel
Deploir can support migrations away from Vercel, but the work is staged deliberately: repository audit, runtime review, environment mapping, staging validation, domain cutover planning, and post-launch stabilisation.
1. Audit the existing workload
The first step is to map repository structure, runtime expectations, auth callbacks, environment variables, domains, storage, background jobs, and third-party dependencies.
- Check whether the workload is static export, server-rendered, or hybrid.
- List every external callback, secret, queue, cron, and storage dependency.
- Identify any Vercel-specific behavior that needs replacement or review.
2. Prepare a staging validation path
Before cutover, Deploir prepares a non-production path to verify build behaviour, routing, SSL, headers, health checks, and recovery assumptions.
No zero-risk migration claim
A managed migration still needs practical validation. DNS, callbacks, scheduled jobs, and rollback readiness are reviewed explicitly.
3. Cut over deliberately
Traffic moves only after the route, certificate, health path, and stakeholder sign-off are aligned. Deploir treats DNS and traffic change as an operational event, not a hidden background detail.
| Cutover item | Expectation |
|---|---|
| Domain ownership | Named owner available during the cutover window |
| Rollback target | Previous working route or deployment retained |
| Health check | Verified after promotion |
| Monitoring | Early post-cutover observation stays active |