Migrate to Easel

Move an existing application to Easel while preserving the familiar Git, Preview, and Production workflow.

Some source-platform features and configuration may need to be translated.

Migration phases

A safe migration has six phases:

Inventory
   ↓
Import
   ↓
Translate configuration
   ↓
Validate
   ↓
Cut over traffic
   ↓
Retire the old platform

Keep the previous platform available until the Easel deployment is stable and the rollback window has passed.

1. Inventory the application

Record:

Repository and framework
Root directory, install command, build command, output directory
Runtime version
Environment variables (Preview and Production)
Functions and middleware
Redirects, rewrites, and response headers
Image behavior
Cache and revalidation behavior
Scheduled or background work
Storage and databases
Webhooks
Domains
Deployment protection and firewall rules
Log drains and observability integrations
Monorepo path filters
Git deployment settings

A successful build does not prove that every platform dependency has been migrated.

2. Confirm framework support

Review the matching framework guide.

Pay particular attention to:

Server rendering and static generation
Streaming and middleware
Image optimization
Caching and revalidation
Function limits and regions

3. Import the repository

Import the same GitHub repository into Easel.

Do not change production DNS yet.

Review:

Framework detection
Root directory
Build commands
Production branch
Preview behavior
Environment variables

See Getting started.

4. Translate platform configuration

Platform-specific files and features may not transfer directly.

Examples include:

vercel.json
netlify.toml
_redirects
_headers
Platform-specific function directories
Platform-specific runtime APIs

Use the source-platform migration guide to map each feature to Easel. Easel does not automatically import Netlify or full Vercel project configuration.

5. Validate outside Production

Use the unique Easel deployment URL or a Preview URL.

Test homepage, deep links, authentication, APIs, databases, static assets, images, redirects, cache behavior, webhooks, and error pages.

See Production validation checklist.

6. Prepare the domain cutover

Before changing DNS:

Add the domain in Easel
Record existing DNS values
Preserve MX, SPF, DKIM, DMARC, and verification records
Lower the relevant TTL in advance
Keep the previous platform active
Define a rollback threshold

TLS certificates are issued after DNS points at Easel. See Domain cutover and Migrate a domain.

7. Cut over traffic

Update the DNS record shown by Easel:

Apex: A records to the edge IPs in the dashboard
Subdomain: CNAME to cname.easelusercontent.com

Monitor error rate, latency, TLS, authentication, webhooks, and cache behavior in Observability and Logs.

8. Roll back when necessary

Restore the previous DNS record when production validation fails or error levels exceed the agreed threshold.

DNS rollback is not instantaneous for clients that cached the new answer.

See Migration rollback.

9. Retire the previous platform

After the migration is stable:

Confirm traffic no longer reaches the previous platform
Remove obsolete domains and redirects
Revoke old deployment tokens
Rotate credentials that no longer need access
Disable old build hooks
Archive required logs
Cancel the old plan when appropriate

Do not delete the old project until the rollback window has passed.

Multi-application migrations

For several applications, start with a representative, lower-risk service.

Run it long enough to observe normal deployments, production traffic, operational incidents, billing, cache behavior, and at least one release or rollback cycle. Then migrate more critical applications using the validated process.

Choose your migration guide