Migrate data from Bolt Cloud to PostgreSQL: orders, users, and storage
Published on 2026-10-27 by frfrand
How to plan a Bolt Cloud to PostgreSQL migration: model, export, data integrity, Auth, functions, and testing.
The mistake of copying only the frontend
An application with orders is not migrated just because the catalog looks good. What matters is in the tables: customers, products, payments, statuses, users, and files. If any of that is still behind a previous provider's API, you have a dependency that you must document, maintain, or replace.
The export depends on how you built the project
Bolt offers different backend services and connections. Before promising a direct migration, find out what database your project uses and what data export or transfer methods are available. Do not assume that all plans include the same button. If there is managed Auth, a CSV export of orders does not solve sessions, passwords, or permissions.
Example: 1,250 orders without duplicating the money
Suppose a clothing store with tables customers, orders, items, and payments. You export the current state without modifying production, create in PostgreSQL the primary keys, relationships, and constraints, and import in order. You compare counts, sums by currency, and payment statuses. A purchase already charged is not charged again for having moved the records. You test dummy orders with the new backend and confirm that each user only queries their own data.
Recommended procedure
1. Document entities, relationships, permissions, and exact data origin. 2. Keep an original backup and an inventory of functions and storage. 3. Prepare versioned SQL migrations, indexes, and constraints. 4. Import into staging and measure integrity; never overwrite the source until validated. 5. Reconfigure credentials, Auth, callbacks, and file paths. 6. Plan a cutover window and verify that no ongoing operations are lost.
Comparison: Managed PostgreSQL or on VPS
In a managed service you delegate part of updates and backups; on your VPS you control the machine, but you also assume backups, restoration, and availability. Data portability is an advantage only when you can rebuild the entire application.
Frequently asked questions
### Does a CSV include RLS permissions? No. It describes rows, not policies or server objects. ### Can I keep the frontend in Bolt? It may be possible, depending on whether the project supports the chosen backend and its integrations. ### How do I verify that all orders arrived? Counts, amounts, related keys, and tests of real operations with test data. ### What do I do with accounts? Migrate via a compatible Auth mechanism, or prepare password changes when appropriate.
Sources
Bolt Cloud and managed services · PostgreSQL: backups.
ArduMaker and the future migration service
Once the code has been audited, ArduMaker can serve as deployment infrastructure according to the stack: VPS, services, domain, certificates, and operational tools. This does not guarantee that the AI-generated application is already secure, nor that moving data is automatic. The page ardumaker.com/lovable is being prepared to present a migration and deployment service from AI builders to production environments; it is not yet published. For now, you can learn about the platform at ardumaker.com. The decision to migrate should be based on concrete requirements, not on a supposed obligation to abandon the current provider.
Updated: October 2026. The functions, plans, and exports of these platforms may change. Check the current documentation and back up real data before intervening.
What the photograph shows
Frontend audit and base records. Illustrative photograph generated to accompany this guide on migrating applications created with AI; it is not a screenshot of the platform nor does it certify a specific installation.
Continue with these practical ArduMaker guides
- From Bolt.new to production: GitHub, server, and stable deployment with ArduMaker - From simulated data to real PostgreSQL: completing the database of an app made with AI - Real payments in an app made with AI: Stripe, webhooks, and idempotency
If you are evaluating your own application, compare the real backend, database, authorization, and deployment requirements before choosing the server.