Migrate to Easel

Move an existing application to Easel while keeping your Git, Preview, and Production workflow. Application code usually transfers unchanged; the work is in translating platform configuration and replacing platform services.

For a platform-specific mapping, see Migrate from Vercel or Migrate from Netlify. For any other host, follow the phases below.

1. Inventory the application

Separate what belongs to the application from what belongs to the current platform, and record both:

• Build: repository, framework, root directory, install, build, and output settings, runtime version, and generated artifacts.
• Environment variables: Preview and Production values, including which are needed at build time.
• Runtime: functions, middleware, containers or persistent processes, WebSockets, background and scheduled work, filesystem use, native binaries, and region or private-network requirements.
• Delivery: caching and invalidation, redirects, rewrites, headers, image optimization, custom error pages, and domains.
• Security: firewall rules, rate limits, and preview access protection.
• Managed services: databases, object storage, queues, authentication, email, forms, analytics, feature flags, and secret managers.
• Operations: log drains, monitoring integrations, webhooks, deploy hooks, and rules that skip builds (see Skipping deployments).

Mark each item as supported by Easel, supported differently, replaced by an external service, or no longer needed. Easel doesn't replace managed data services, and incoming WebSockets aren't supported (see Functions runtime), so plan replacements before cutover.

2. Import the repository

Import the same GitHub repository into Easel, or deploy it with the CLI. Don't change production DNS yet. Compare the detected build configuration with your current settings, add environment variables, and review the matching framework guide.

3. Translate platform configuration

Easel doesn't import netlify.toml, _redirects, _headers, or other platform-specific function directories and runtime APIs. Map each one to framework-native configuration or the Easel equivalent, using the source-platform guide where one exists.

4. Validate and cut over

Test through a deployment URL until the cutover checklist passes. Then move the domain with Migrate a live domain, keeping the previous platform running so you can roll back.

5. Retire the previous platform

Once traffic has moved and your rollback window has passed:

• Confirm traffic no longer reaches the previous platform.
• Revoke old deploy tokens and build hooks, and rotate credentials that no longer need access.
• Archive any logs you need to keep.
• Remove obsolete domains and redirects, then delete the old project.

Migrate several applications

Start with a representative, lower-risk application. Run it through normal deployments, production traffic, and at least one release and rollback before you migrate more critical ones with the same process.