Cutover checklist

Work through this checklist against the Easel deployment URL before you change production DNS. The DNS steps themselves are in Migrate a live domain.

Validate before cutover

Deployment

• The expected commit is deployed to Production, and the deployment is Ready and Current (see Promote and roll back).
• Framework detection and build settings match the application.
• No unexplained build warnings.

Routes and rendering

• Homepage, deep links, and dynamic routes.
• Server-rendered, static, and API routes.
• Redirects and rewrites, including status codes and wildcards.
• Custom error and not-found pages.

Authentication and sessions

• Sign in, sign out, session refresh, and password reset.
• OAuth callbacks registered for the new hostname.
• Cookie domain, Secure cookies, and CSRF protection.
• Authorized and unauthorized routes behave correctly.

Data and integrations

• Database reads and writes.
• File uploads and object storage.
• Email, webhooks, and third-party APIs, with callback URLs updated.
• Queues, background work, and scheduled jobs on their replacement scheduler.

Delivery

• Static assets, images, and fonts.
• Cache headers and X-Easel-Cache outcomes (see Caching).
• Revalidation and streaming responses.

Security

• Firewall custom rules recreated where the application needs them.
• Attack challenge mode off unless you need it.
• Deployment protection set correctly for previews.
• Security headers and CORS.
• Secrets scoped correctly to Preview and Production.

Observability

• Requests appear in Logs, with function output and traces where expected.
• Baseline error rate and latency recorded, so you can compare after cutover.

Failure behavior

• Missing routes, application errors, and upstream timeouts return the expected responses.
• Invalid authentication and bad webhook signatures are rejected.

Sign-off

Record the validated deployment ID and commit, who validated it, known limitations, and the rollback criteria: the conditions, agreed in advance, under which you'll move traffic back. Common triggers are critical paths down, failed sign-ins, payment or webhook failures, TLS errors, data corruption risk, and sustained error or latency regressions.

Roll back a cutover

A cutover rollback points DNS back at your previous platform. To switch to an earlier deployment inside Easel without touching DNS, use Promote and roll back instead.

Before cutover

Record the previous DNS record type, value, and TTL, the previous platform project, the credentials you'd need, and who makes the call. Keep the previous application and its services running until the migration is done.

Restore traffic

When a rollback criterion is met, follow Roll back the cutover and restore the record you recorded rather than recreating it from memory. Clients that cached the Easel answer keep reaching Easel until it expires, so monitor both platforms and avoid destructive changes on either.

Then confirm that DNS resolves to the previous platform, HTTPS, sign-in, critical writes, and webhooks work, the error rate is back to baseline, and traffic on Easel is falling.

Preserve evidence

Keep the Easel project while you investigate. Save the deployment ID, request IDs, traces, logs, DNS change timestamps, and monitoring data. See Observability troubleshooting.

Before the next attempt

Fix the failure and reproduce the fix outside Production. Then repeat this checklist and the domain cutover with the rollback plan ready again.