Moving a Replit app: copy the right database and lose no writes

Replit is one of the friendlier platforms to leave. Your app is conventional code, and its data is in PostgreSQL, so standard tools do most of the work. The risks are small assumptions that cause big trouble on the day: copying the wrong database, losing the last few writes, and forgetting the things that never copy across.

This guide covers what moves with standard tools, what you have to recreate, the three mistakes to avoid, and a step-by-step checklist.

What moves with standard tools

Replit's guide to copying a project treats code and data as separate steps, using GitHub or a zip for the code and standard PostgreSQL tools for the data. It's written for moves between Replit workspaces, and the same tools work anywhere else.

• Your source code, through GitHub or a zip download
• Your commit history, if you use Git
• Your PostgreSQL schema and records, using pg_dump and pg_restore

What never copies across

• Secret values and Account Secrets. Keep your own copy of every key.
• App Storage buckets and the files in them
• Connectors, deployments and custom domains, which need setting up again
• Files ignored by Git and uncommitted changes, if you move the code through Git

Three mistakes to avoid

1. Exporting the development database

Replit's DATABASE_URL points to the development database, while your live data is usually in production. Export without changing it and you copy test data, and the move looks like it worked. Confirm you're connected to production before you run the dump.

2. Losing the last writes

Anything written after the dump runs isn't in the copy. Replit advises unpublishing the old app before the final dump, so plan a short maintenance window and tell your users.

3. Leaving the dump file lying around

A database dump is a full copy of your data. It shouldn't be committed to Git, and Replit advises deleting it from both projects and your device once the copy is done.

A step-by-step Replit exit checklist

1. Back up production. Take an independent dump of the production database and check that it restores.
2. Take inventory. List secrets, storage buckets, connectors, custom domains and the runtime your app needs.
3. Make the deployment reproducible. Put the code in a repository you control and confirm it builds and starts on your new host.
4. Rehearse the data move. Restore a copy of production to the new database and verify it, so the real cutover isn't the first attempt.
5. Unpublish and take the final dump. Stop new writes, dump production and restore it.
6. Set secrets and domains on the new host, then check the core workflows.
7. Delete the dump files from every place you copied them.

If you'd rather hand it over, every Replit web app is a flat $199 with AppExit, code and database included, whatever its size. The Replit migration guide shows how we run each step.

Frequently asked

Is Replit an easy platform to leave?

Compared with many builders, usually yes, because it uses standard code and PostgreSQL. The details still depend on each project's runtime and services.

Will there be downtime?

Plan for a short maintenance window during the final copy, because Replit advises taking the old app offline so no writes are missed. A rehearsal tells you how long it will take.

How do I keep AI agents away from my live data?

Separate development and production, and keep your own backups. Our guide to AI coding agents and production data covers the guardrails.

Sources

Vendor documentation checked November 2026. Plans and export paths can change. AppExit is not affiliated with Replit.