Migration
Migration rollback
Return traffic to the previous platform when a production cutover fails.
A migration rollback restores the previous traffic destination.
It is different from an Easel Instant Rollback, which switches between deployments inside Easel without changing DNS.
Before migration
Record:
- Previous DNS record type
- Previous DNS value
- Previous TTL
- Previous platform project
- Required credentials
- Validation commands
- Responsible operator
Keep the previous application and services running.
When to roll back
Use the criteria established before cutover.
Typical triggers include:
- Critical application paths unavailable
- Authentication failure
- Data corruption risk
- Webhook or payment failure
- TLS failure
- Sustained error increase
- Severe performance regression
Restore DNS
Replace the Easel routing record with the recorded previous value.
Do not guess or recreate the value from memory.
Understand propagation
Some users may continue reaching Easel until their cached DNS answer expires.
During rollback:
- Keep both platforms operational
- Monitor traffic on both
- Avoid destructive configuration changes
- Communicate partial recovery accurately
Verify recovery
Confirm:
- DNS resolves to the previous platform
- HTTPS works
- Authentication works
- Critical writes work
- Webhooks succeed
- Error rate returns to baseline
- Traffic decreases on Easel
Preserve evidence
Keep:
- Easel deployment ID
- Request IDs and Trace links
- Logs and error screenshots
- DNS timestamps
- Monitoring data
Do not delete the Easel project while investigating.
Prepare the next attempt
Before another cutover:
- Identify the failure.
- Reproduce it outside Production.
- Correct the application or configuration.
- Repeat the Production validation checklist.
- Confirm rollback readiness again.