Migrate to Pierrr

What a migration does

The migration assistant takes an app that already runs on another host and recreates it on Pierrr: a project, a container built from the same Git repository, the same build settings and the same production variables. It then starts the first deployment.

The assistant never stops the original app. Until you change the DNS of your domains, your current host keeps serving the site: you check the Pierrr version on its Pierrr address, then switch when you are ready.

A beta feature

The migration assistant is in beta: it is open to every organization, and we refine it as your feedback comes in.

A migration starts from the Projects page: click Create a project, then choose Migrate from another host. The option is open to members who can create projects, as long as your plan's project quota is not reached: a migration creates a new project.

Supported hosts

Each host has its own connector, and they arrive one after the other:

• Available: Vercel. The step-by-step guide is on the Migrate from Vercel page.
• For an application hosted on your own server, follow the checklist for migrating an existing application.
• Announced: Netlify, Render, Railway, Heroku, Coolify, OVHcloud and IONOS. They appear as Coming soon in the list of hosts, with no date for now.

The steps at a glance

A migration always follows the same path, in a wizard whose progress bar has five steps:

1. Connect: you give Pierrr read access to your account at the host, with a token you create yourself.
2. Project: you pick the account or team, then the project to migrate.
3. Analysis: Pierrr reads the project and shows you what will be imported, how the app will be built and what needs your attention.
4. Import: Pierrr creates the project, imports the variables and starts the first deployment.
5. Done: the app is imported and the step is checked. From the result screen you still copy the data and switch the domains, then finish the migration, which erases the access given to Pierrr.

The wizard page, Migrate from another host, carries a Beta badge and lists your recent migrations with their status (Connected, Analyzed, Import running, Imported, Finished, Failed, Cancelled). The Open button reopens one.

After the import

The Application imported screen sums up what was just created:

• The first deployment: its status (an animated dot while it runs), duration, source (branch and commit) and start time. It updates by itself until it ends; Follow the deployment opens its detail and Open the project opens the project.
• The variables, in a two-column table, Variable and Status: Imported, Provided by the Pierrr database, or Not imported when the value is missing.
• A What's next reminder: check the app on its Pierrr address before switching your domains. Before the import, Cancel the migration remains available.

1. Import (continued): if the app uses a database, Pierrr can copy its content into the project's database, from the result screen.
2. Import (continued): from the same screen, Pierrr prepares your addresses and tells you which DNS records to set, or sets them for you when the host manages your DNS.

If something goes wrong

Three situations have their own screen:

• The import failed: the error is shown, so start a new migration.
• Migration cancelled: the token is erased and nothing was created.
• Token expired: after 24 hours the token is erased; start a new migration. An import that has not progressed for over ten minutes is flagged, with the advice to cancel and start over.

What carries over

The analysis finds and imports:

• The app's Git repository and its root directory in the repository.
• How to build it: a Pierrr template suited to its framework, or the repository's Dockerfile.
• The production variables, imported and bound to the app.
• The detected database, whose data you can copy into the project's Pierrr database, or which you can keep on a paid plan.
• The domains, moved after the import, once the app runs on Pierrr.

What does not carry over

Some features specific to the original host have no direct equivalent. The analysis flags them before the import:

• Scheduled jobs.
• For a site built as static files, serverless functions and server-side rendering: only the built site is served.
• Preview deployments.
• Variables the host provides itself, which do not exist on Pierrr.

Security and privacy

A migration is designed to leave nothing behind:

• Pierrr reads your project on the host and writes nothing there. The one exception is the automatic DNS switch, which you trigger yourself and confirm by typing the project name.
• The access token is kept encrypted for 24 hours at most. It is wiped at the end of the migration, on failure, if you cancel, or after 24 hours, and it is never shown again.
• We recommend a token scoped to the project's team that expires after one day: even if forgotten, it is useless the next day.
• A connection string you paste to copy your database is used for that copy only: it is never stored, and the copy requires an encrypted connection.
• During an automatic DNS switch, only the address records of the migrated names change. Your email and other records stay as they are, and the old ones are kept so you can go back.

Migrate without downtime

The recommended order keeps your site online from start to finish:

1. Import the app.
2. Check it on its Pierrr address, once its first deployment has succeeded.
3. Copy the database data, if the app uses a database.
4. Switch the domains.
5. Finish the migration.

Until the DNS changes, your current host serves the site: your visitors see nothing of the earlier steps.