To move an app off Lovable, Bolt or Replit, export every record first, write down what the app actually does (screens, fields, rules, roles and alerts), rebuild it on the new platform from that description, run both side by side for a week, then switch over and shut the old one down properly. For a team without developers, rebuilding from a clear description is usually faster and safer than trying to move the code itself.
To move an app off Lovable, Bolt or Replit, export every record first, write down what the app actually does, rebuild it on the new platform from that description, run old and new side by side for about a week, then switch over and shut the old one down completely. The description is the part people skip and the part that matters most: every screen, every field, every rule about who sees what, every alert and every report. With that in hand, a team without developers can move a working tool in days instead of trying to transplant code nobody on staff can run.
People usually start looking for the exit for one of four reasons. The bill is hard to predict, the app has become important enough that the company needs roles and a record of every change, someone worries about where the data lives, or the person who built it is leaving. Each reason changes what you should check on the way out, so it helps to name yours before you start.
Why teams outgrow prompt-first builders
Lovable, Bolt and Replit are very good at turning a typed idea into a working app quickly. The friction shows up later, once the app is part of daily work.
- The meter. Lovable's pricing page says one credit balance pays for building, hosting and AI features inside your apps. Bolt prices by tokens, and its pricing page says Teams tokens belong to each member rather than a shared pool. Replit charges for agent work from a credit balance; in October 2026, users on Replit's own forum described agent bills of $500 to $1,000 a month, and The Register covered complaints about cost spikes when Replit launched Agent 3 in September 2025. These are individual reports, but they describe the pattern finance leads worry about.
- Controls on the top tier. As listed in October 2026, Lovable puts SCIM, audit logs and data exports on Enterprise; Bolt lists SSO and audit logs as Enterprise features; Replit lists SSO, SCIM and audit logs as Enterprise only.
- Exposure. In May 2026, Axios reported research by RedAccess that found thousands of AI-built apps and pages, on platforms including Lovable and Replit, exposing sensitive data. Lovable has also published its own account of a 2026 regression that exposed public projects' chat history and source code.
- Reliability. StatusGator's record of Replit's status page shows a run of outages in 2026. When a crew starts its day in the app, downtime becomes a staffing problem.
None of this means the tools are bad. It means a tool that was perfect for a prototype may not be the right home for something the whole company now runs on.
Step 1: Take stock of every app
Before moving anything, list what exists. Shadow apps tend to multiply, and a move is the right moment to find them all.
For each app, write down:
- Name and purpose in one sentence.
- Who built it and whose account it lives in, personal or company.
- Who uses it and how often.
- What data it holds: customers, employees, prices, payments, health or financial details.
- Where the data lives: inside the platform's own database, a connected service, or a spreadsheet the app reads.
- Whether it is public: open the link in a private browser window without signing in and see what loads.
- What it costs each month, including credit top-ups.
Then sort the list into three groups: move it, merge it into another tool, or retire it. A surprising number of apps were experiments nobody opens anymore. Retiring them is the cheapest migration there is.
Step 2: Export your data before anything else
Your data is the one thing you cannot rebuild from memory. Export it first, while you still have full access to the old account.
- Export every table in a standard format such as CSV. If the app has customers, jobs and notes, that is three exports.
- Include files and photos. Attachments are often stored separately from the records and are easy to miss.
- Keep the links between records. If a job belongs to a customer, make sure the export shows which customer, usually by an ID column.
- Capture history if you need it. Status changes, approvals and comments may live in their own tables.
- Open every export. Check the row counts against what the app shows. An export that stops at a thousand rows, or drops a column, is common and easy to fix now and impossible to fix after you cancel.
- Store the exports in a company account with access limited to the owner and admin.
If you are on a plan where some exports are restricted, plan the timing so you have what you need before you downgrade or cancel.
Step 3: Write down what the app really does
This is the specification for the new tool, and the old app is the best source for it. Click through every screen and record what you find. Most of the value is in the rules nobody wrote down.
Screens and fields
List each screen and every field on it, with its type: text, number, date, choice from a list, photo, signature, yes or no. Note which fields are required.
Rules
Write each rule as a plain sentence. "A job cannot be closed without a photo." "Orders over $2,000 need the owner's approval." "When the status changes to Scheduled, text the customer." These are the parts the AI wrote into the old app that you will otherwise lose.
Roles
Who can see what, and who can change what. In many prompt-first apps there is only one level of access, because everyone signs in the same way. The move is your chance to fix that: technicians see their own jobs, the office sees all jobs, the owner sees money.
Alerts and reports
Every email, text or reminder the app sends, who gets it and when. Every report or export people rely on, and who reads it.
What annoys people
Ask three regular users what they wish worked differently. A move is the cheapest moment to fix it, because you are building the tool fresh anyway.
| What to capture | Example from a job request app | Why it matters |
|---|---|---|
| Fields | Customer, address, job type, priority, photos, notes | The new tool must hold the same records |
| Rules | High-priority jobs alert the dispatcher immediately | Rules are invisible until they stop working |
| Roles | Techs see their jobs; office sees all; owner sees revenue | Most prompt-first apps never had real roles |
| Alerts | Customer gets a text when a tech is on the way | Customers notice when these stop |
| Reports | Weekly jobs completed by tech | Managers rely on them without saying so |
Step 4: Decide how to rebuild
You have two broad options.
- Move the code. Take the exported code to a hosting service and keep running it. This fits a company with a developer who will own hosting, sign-in, security updates and fixes from now on.
- Rebuild from the description. Give your written description to the new platform and have it build the tool fresh. This fits a company without developers, and it has a quiet advantage: you get to fix the rough edges and add proper roles at the same time.
For most small and mid-size businesses, the second option is faster and safer. The old code was written to the old platform's way of doing things. Making it run somewhere else is developer work, and the developer you would need is the person you were trying not to hire.
Step 5: Run old and new side by side
Do not switch everyone over on a Monday morning and hope.
- Load a copy of real data into the new tool, or test records that look like it.
- Test it with the checklist from our guide to testing an AI-built app before launch: sign-in, roles, a signed-out visitor, a low-access user, a removed user.
- Pick a cutover date and tell everyone.
- Run both for about a week. New work goes into the new tool. The old one stays readable so nobody loses a reference.
- Move the final records that changed during the week.
- Compare counts. Open jobs, customers, unpaid invoices: the numbers should match.
Step 6: Shut the old app down properly
A half-closed app is a risk. It still holds your records, and on some platforms it may still be reachable.
- Unpublish the app and remove any public or shared links.
- Delete the data from the old database once you have confirmed the export and the new tool.
- Revoke keys and passwords the old app used to reach other services, such as email or payments, and create new ones for the new tool.
- Remove former staff from the old workspace before you close it.
- Cancel billing, including automatic top-ups.
- Check the address once more in a private browser window. Nothing should load.
Mistakes to avoid
- Cancelling before exporting. Once the account is gone, so is your leverage. Export, check, then cancel.
- Moving every app at once. Start with the one that matters most, learn, then move the rest.
- Copying the old app exactly. You are rebuilding anyway. Add the roles and the record of changes the old one never had.
- Forgetting the outside connections. Payment links, email sending and calendar sync often break silently during a move.
- Leaving the old app running "just in case." Set a firm date to shut it down. A forgotten app holding customer records is exactly how exposures happen.
- Doing it without the people who use it. The dispatcher knows rules the builder forgot. Ask them.
How to know the move worked
Two weeks after cutover, check:
- Every regular user has signed in to the new tool and nobody is using the old one.
- Record counts match the export, and no one has reported missing work.
- The old address returns nothing and old keys no longer work.
- The monthly cost is the number you expected.
- When someone asks who changed a record, you can answer from the record of changes rather than from memory.
Example request
Example request: "We are moving our service request app off Lovable. Rebuild it for our 20-person plumbing company. Customers call or email, and the office enters a request with customer name, phone, address, job type from a list, priority (normal, urgent, emergency), description and photos. Each request gets a status: new, scheduled, in progress, waiting on parts, done, invoiced. The dispatcher assigns a technician and a date. Technicians see only their own jobs on their phones, add notes and photos, and mark the job done; a job cannot be marked done without at least one photo. Emergency requests alert the dispatcher by text right away. When a job is scheduled, text the customer the date. Office staff see all jobs; only the owner sees the revenue report, which shows jobs completed and invoiced by technician each week. Roles are owner, office, dispatcher and technician. Only invited people can sign in. We will import about 1,800 past requests and 900 customers from CSV files."
How FORGE handles it
On FORGE, the description you wrote in step 3 becomes the request. Your team says what the current app does, and what they wish it did, in plain words. A panel of top AI models plans the tool, a dedicated AI crew builds it, and every piece is checked for quality and security before it is saved. Most teams have their first real tool running the same day, so the side-by-side week can start almost immediately.
The new tool gets what most prompt-first apps never had. Every app lives inside your company and nothing is public. People join only by invite, owners, admins, builders and app users each see what their role allows, and there is a complete record of who did what. When someone leaves, removing them ends their access while their tools stay with the company.
The bill is easy to forecast: $49 a seat a month for each person who builds, with 3 builds included, a flat $10 a user a month for people who only use the tools, and packs of 10 builds for $150 when you need more. Fixes are part of every build, and nothing extra is ever charged without your OK. Our team onboards every company ourselves and plans the move with you, starting with the app your team leans on most. Talk to us or see pricing.
Questions people ask
Can I just export my code and run it somewhere else?
You can often get the code out, but code on its own is not a running app. Someone has to host it, connect it to a database, set up sign-in, keep it secure and fix it when it breaks. If nobody on your team does that work today, a code export is a file, not a plan.
Will I lose my data if I leave?
Not if you export it before you cancel. Pull every table out in a standard format such as CSV, include files and photos, and open the export to check it is complete. Do this while you still have full access to the old account.
How long does a move take?
For a single internal tool with a clear description, the rebuild itself can be quick. Plan for about a week of running the old and new tools side by side so nothing gets lost, plus time to check the data and train the team.
Should we move every app at once?
No. Move the app your team depends on most first, learn from it, then move the rest in order of importance. Retire small apps nobody really uses instead of moving them.
What do we need to shut down on the old platform?
The published app, any public links, the database behind it, saved keys and passwords, and the billing. Confirm the old address no longer shows anything in a private browser window before you call the move finished.
How does FORGE help with a move?
Your team describes what the current app does in plain words and FORGE builds it, checked for quality and security at every step. Our team plans the move with you during onboarding, starting with the app that matters most to daily work.
See what FORGE builds for your team
We onboard every team ourselves, starting with the work that costs you the most time.
Talk to us
