GitHub
Repository import with branch selection, so the revision that is analysed is the revision that gets migrated.
MIGRATION CENTER
Move without the leap of faith.
Import a project, let it be analysed, preview it on real infrastructure and verify it — with your current site still serving until the cutover has been checked.
In development: the Migration Center foundation is in the current work queue and no migration can be started today. The sources, states and verification rules below are the design contract being built — not a live import path.
Bring the project from where it is.
Import sources are added as source-specific flows on top of one migration job model: repositories and archives first, then the platform-specific ones.
GitLab
The same repository flow against GitLab, using the project permissions you already have.
Vercel
A source-specific flow for projects already running on Vercel, including their build settings.
Lovable
A source-specific flow for Lovable projects, so the export does not have to be assembled by hand.
ZIP archive
Upload an archive when there is no repository at all — the job model treats it like any other source.
Static website files
Plain HTML, CSS and assets import as a static project with no build step to configure.
WordPress
A source-specific flow for WordPress sites, planned after the repository and archive paths.
SSH / SFTP
Pull from a server when the code only exists there, without inventing a repository first.
Custom Git
Point at any Git remote with your own credentials, for hosts outside the first wave.
A migration is a job with explicit states and progress you can follow, not a black box that reports success at the end.
Not usable yet: none of these sources can be imported today — the import flows are in the work queue, and each card describes what that source is specified to do.
Nine states, and nothing jumps ahead.
Every migration is a job that moves through named states. A job that cannot continue stops in a terminal state instead of pretending to finish.
- analyzingThe source is read and checked: framework, build command, environment variables, backend usage and anything unsupported.
- readyThe analysis has produced a plan and a compatibility report you can read before anything moves.
- importingSource is copied into a managed project with its own private repository and version history.
- buildingThe project builds in an isolated sandbox — no network, with hash-verified artifacts.
- testingDesigned to run the checks the analysis marked as critical before the site is exposed.
- waiting_for_customerAnything the platform cannot read — unreadable secrets, a decision, a confirmation — waits here with a clear list instead of a guess.
- switchingDNS or routing is switched to the new version. This is the only state that changes where visitors land.
- verifyingThe switched site is verified on the real domain, with the source system still intact.
- completedThe job is done, and the old source can be retired whenever you choose to retire it.
rolled_back — terminal statefailed — terminal state
Terminal states are first-class: rolled_back and failed are real outcomes, not hidden retries — and the source system is always preserved until the cutover has been verified.
Hosting migrates first. The backend is your call.
Moving the frontend and moving the backend are two separate decisions, and both are part of the Migration Center being built. Step B never happens by itself.
Step A — always first
- Import sourceRuns first
- Version historyCreated for the new project
- Frontend deployTo preview, then production
- Existing backendLeft unchanged
- Backend moveNot part of this step
Step B — explicit and optional
- TriggerOnly when you choose it
- Backend providerMigration capabilities used where they exist
- Data, users, storageMigrated where supported
- Application bindingsRewritten against the new backend
- Test suiteAuth, database, uploads, critical flows
Backend conversion is never forced during a frontend migration — if the current backend works, it stays exactly where it is.
Secrets are never guessed.
Environment variables that cannot be read from the source are surfaced as items that need your confirmation — with a count, never with an invented value.
Never faked: if a secret cannot be read, the migration says how many values require confirmation. It does not invent a value, and it does not pretend the import succeeded.
MIGRATION #4821 state: waiting_for_customer DATABASE_URL from source STRIPE_SECRET_KEY from source SMTP_PASSWORD requires confirmation SUPABASE_SERVICE_KEY requires confirmation STRIPE_WEBHOOK_SECRET requires confirmation 3 secret values require confirmation before the build can continue
Illustrative interface sketch — the wording the confirmation state is specified to use. This is not a live screen.
Supabase is a source, not a default.
Supabase is handled as a migration compatibility source, not as the backend new projects are pushed onto. The flow analyses how it is used and produces a report before any choice is offered.
authtablesrow level securitystoragefunctionsrealtimetriggersSQL functionsextensionscronOAuth
Option A — keep Supabase
The frontend moves, the backend connection stays exactly as it is. Nothing about auth, data or storage changes in this option.
Option B — move the backend
Uses the backend provider’s migration capabilities where they apply, migrates data, users and storage where supported, rewrites the application bindings, rebuilds, then runs auth, database, upload and critical-flow tests.
Stated as limits, not failures: automatic conversion of arbitrary custom PostgreSQL functions, complex triggers, special extensions, Edge Functions and advanced row-level-security semantics is not promised. Blockers are presented before production cutover, so a limitation is something you read in the report rather than something you discover afterwards.
The questions that decide whether a migration is safe.
What happens to the old site, the old backend and the parts that cannot be read.
Will my current site go offline during a migration?
No. The source system is preserved until the cutover has been verified — switching is the only state that changes where visitors land, and rolling back is a first-class state rather than an emergency.
Do I have to migrate my backend too?
No. Frontend first is the rule: import, build, preview and verify with the existing backend connection unchanged. Moving the backend is a separate, explicit step that you choose.
What happens when a secret cannot be read?
The migration stops in waiting_for_customer and tells you how many values require confirmation. Nothing is guessed, and no value is invented to keep the job moving.
Can I migrate a WordPress site?
WordPress is a listed import source and is planned as a source-specific flow after the repository and archive paths. None of it is live yet — the Migration Center is in development.
What if the migration fails after switching?
failed and rolled_back are terminal states you can see, and the preserved source is still there. The platform does not retire your old system — you decide when that happens.
Do I need a GitHub account?
No. Every managed project gets a private repository in the platform’s own source service, and the customer-facing words are Versions, Restore, Compare and Export. Importing a ZIP or static files needs no repository at all.
Move when the flows open.
Join early access for the Migration Center — and get the honest state of the work rather than a demo that cannot run.