From Vibe-Coded MVP to Production: The Order to Do the Work In

Before any code moves, establish which platform primitives the app actually uses. This is an inventory exercise, and it defines the real scope of everything that follows. For a Lovable app that means auditing every Supabase Edge Function, every row-level security policy, every storage bucket policy and every OAuth provider. For a Base44 app it means finding every call to base44.entities, base44.auth and the backend functions in the frontend code, because each one is a service you must replace rather than a URL you can re-point. Base44's architecture routes every data read and every login through its SDK to Base44 servers, which is what makes the export and the migration two very different things. The reason this comes first is that everything downstream is estimated from it. You cannot size the auth work without knowing how many providers are configured. You cannot size the data work without knowing how many tables carry relationships. Teams that skip this step do not skip the work, they just discover it one surprise at a time. The output should be a written list, not a mental model. Every authentication provider, every bucket, every scheduled job, every integration and its credentials, every backend function. Founders routinely find this list is twice as long as they expected, and that discovery is cheap here and expensive later.

Audit the app for security problems while it still lives where it was built. Migrating a vulnerable app to new infrastructure does not fix the vulnerability, it just relocates the breach to somewhere you have less visibility. The base rate justifies assuming exposure until you have proven otherwise. Escape scanned more than 5,600 publicly available vibe-coded applications in October 2025 and found 2,038 highly critical vulnerabilities, over 400 exposed secrets and 175 distinct instances of exposed personally identifiable information including bank account data. More than fifty tables accepted unauthenticated writes, including tables named payments, orders and transactions. Escape scanned passively for ethical reasons and states that the findings "reflect only a subset of exploitable issues", so it is a floor. The specific enumeration to run is short. Check every table's row-level security state. Check every secret that appears in the client-side bundle. Check every remote procedure callable with the public anon key, including admin functions. CVE-2025-48757 documents exactly this class of failure across Lovable projects, where inspecting network traffic and substituting a query returned entire tables. Matt Palmer's disclosure found 303 vulnerable endpoints across 170 websites from examining homepages alone. Doing this first also changes the migration plan. If a table has been readable by anyone for six months, the correct response is disclosure and credential rotation, not a quiet lift-and-shift that carries the same policy into production.

Authentication is the first thing that breaks in every migration and the largest single time sink, so it goes first and it goes alone. Copying components across feels like progress, but nothing downstream can be properly tested while login is broken. That is the whole argument. A migrated app with working components and broken auth cannot be verified at all, because you cannot reach any authenticated route to check whether the component behind it works. Teams that port the easy visual layer first end up with a large volume of unverified code and no way to test it, which is worse than having less code that works. The technical cause is documented and checkable on the most common path. Lovable generates apps using the standard browser Supabase client, which handles sessions in the browser only. Moving to a framework with server-side rendering requires the server-side Supabase package instead, because sessions now need to persist across both server and client components. Agencies selling this migration all describe the same failure sequence: auth callbacks break first, then import paths fail on the build server, then routing takes about twice as long as estimated. Those are commercially interested sources, but the auth mechanism they describe is verifiable in the packages themselves. Budget for the password problem in this step too. Lovable's documentation states that user passwords cannot be exported and a reset flow must be triggered. Base44 has the same constraint through its private authentication records. That reset is a user communication task with a date attached, not a code task, and it needs planning before cutover week.

Schema before data, and both before anything that reads from them. On a Lovable app this is the genuinely automated part of the whole migration, which makes it a poor place to spend anxiety and a good place to spend care. Lovable's schema, storage bucket policies, indexes, functions and triggers travel as SQL migration files that run in timestamp order, with the Supabase CLI push and diff commands available to verify the result matches. Data is the manual part: CSV per table, or a full database export capped at 5 GB with one export permitted per 24 hours. That cooldown is a scheduling constraint on rehearsals, and it is worth knowing before you plan the week. Base44 has no equivalent automated path. Its store is MongoDB-compatible, so documents must be remodelled for whatever you are moving to, and record identifiers, relationships and field types all have to survive the transfer intact. This is the step where referential integrity breaks silently, because a mismatched identifier does not throw an error, it just returns nothing where a related record used to be. One documented trap belongs here. Lovable's docs warn that you must download your export and your storage files before removing Cloud from the project, because exports saved to Cloud storage are no longer accessible afterwards. That is an irreversible action with no warning attached at the moment you take it.

Every API key, OAuth credential and service token should be regenerated during migration rather than copied across. Treat anything that has lived inside a generated codebase as already compromised. The reasoning is specific to how these apps are built. AI coding tools frequently hardcode the API key you pasted into a prompt, and prompts are not a secure channel. Escape's October 2025 scan found more than 400 exposed secrets across the applications it examined, including keys for Google Maps, payment providers and admin tokens. A key that has been sitting in a client-side bundle is public whether or not anyone has used it yet. Rotation also does useful work beyond security. It forces you to enumerate every credential the app actually holds, which is the same list you started building in step one, and it surfaces the integrations nobody remembered configuring. If a rotated key breaks something you did not know existed, you have found an undocumented dependency at the cheapest possible moment. The general risk picture supports treating generated code as untrusted by default. Veracode's 2025 GenAI Code Security Report, published on 30 July 2025, tested 80 coding tasks across more than 100 large language models and found that when a secure and an insecure implementation were both available, models chose the insecure one 45% of the time. Java was the worst case at a 72% security failure rate. That is not an argument against AI-generated code, it is an argument for reviewing the security-sensitive parts of it rather than assuming they are correct.

Set up environments and automated deployment before you start moving the remaining pieces, because every step after this one needs somewhere to be tested that is not production. Doing it later means testing storage and automations directly against live data. The build-time trap catches people here. Lovable environment variables prefixed with VITE_ are embedded into the bundle at build time rather than read at runtime, so per-environment configuration requires separate builds or separate containers rather than a different set of variables on the same artefact. Anyone expecting twelve-factor runtime configuration will get this wrong once. Deployments should be fully automated pipelines gated on tests, linting and security checks, which is Lovable's own documented recommendation for teams leaving the platform. The gate matters more than the automation. A pipeline that deploys quickly without checks moves you faster in the direction you were already heading. For credentials in the pipeline, use identity federation to your cloud provider rather than long-lived keys stored in repository secrets. This is also documented as Lovable's recommendation, and it follows directly from step five: having just rotated everything because generated code leaks secrets, storing new long-lived secrets in a place that gets copied around undoes the work.

Files and background jobs come after the pipeline exists and before monitoring, because both fail silently and both need somewhere non-production to be verified. These two steps are where migrations quietly go wrong. Storage first. Files must be moved and every URL that points at the old platform's storage rewritten. In Base44 apps, file fields hold URLs still hosted by Base44, so each one is a reference that keeps working right up until the subscription lapses. The failure mode is gradual rather than immediate: images stop loading in ones and twos over weeks, which reads as a flaky bug rather than a migration defect. Automations are worse because there is often nothing to migrate from. Base44 automations, including their schedules, entity triggers, arguments and execution identity, are not present in any export, and neither are agents, conversations, memories or connector OAuth configuration. That claim comes from EscapeBase44, which sells Base44 migrations, though it is consistent with what Base44's documented export mechanisms produce. In practice these have to be rebuilt from observed behaviour, which means someone has to work out what the app was doing on a schedule by watching what it did. This is the category most likely to be discovered missing in production, precisely because a scheduled job that never runs produces no error. Nothing appears in the logs. The only signal is the absence of an outcome that used to happen, and that absence can go unnoticed for weeks.

Monitoring, alerting and rollback procedures must exist before you switch traffic, because at cutover you take on work the platform was doing invisibly on your behalf. This is the step teams most often defer, and deferring it removes your ability to tell whether the previous eight steps worked. Lovable states the boundary plainly in its own documentation: "Lovable cannot monitor or debug production infrastructure it does not control." That is a fair statement of the trade. The platform was handling uptime, scaling, certificates and error visibility as part of the service. On owned infrastructure those become your responsibilities, and they become your responsibilities on the same day, not gradually. What needs to exist before the switch is concrete: error tracking wired into both frontend and backend, uptime checks on the routes that matter, alerts that reach a named human rather than a shared inbox, and a written rollback procedure with the specific commands in it. Alert ownership and escalation paths should be decided while nobody is stressed. Plan for post-launch monitoring to be more intensive than steady-state for the first several days. The failures that matter in a migration are not the ones that page you at cutover. They are the ones that surface on the first weekly scheduled job, the first large file upload, or the first user who signed up two years ago and has an account shape nobody tested.

The final step is testing with actual user accounts and actual production data, not seed data and not a fresh test account created five minutes ago. A migration that has only ever been tested by its own authors is untested in the way that matters. The verification list follows the inventory you built in step one. Log in as several real accounts with different permission levels. Confirm each one sees only its own data. Perform a write, an upload, a function call and an integration action as each. Trigger every automation manually and confirm the outcome, then wait for the scheduled run and confirm it happened on its own. Permissions deserve particular attention because they are the failure with the worst consequences. Row-level security policies that behaved correctly on the old platform can behave differently after a schema migration, and the test that catches this is specifically logging in as user A and attempting to read user B's records. A single admin account will never surface it. The table below sets out the sequence and the constraint that fixes each step's position in it.

Each row states the constraint that determines the position, rather than just the task. If you are considering reordering a step, the middle column is the reason not to. | Order | Step | Why it cannot come later | |---|---|---| | 1 | Architecture and dependency review | Everything downstream is scoped from this inventory | | 2 | Security audit | Moving a vulnerable app relocates the breach instead of fixing it | | 3 | Auth in isolation | Nothing behind a login is testable while auth is broken | | 4 | Database schema, then data | Application code cannot be verified against a schema that does not exist | | 5 | Rotate all secrets | Generated code leaks keys, and every later step will use them | | 6 | Environments and pipeline | Later steps need somewhere to be tested that is not production | | 7 | Storage and file URL rewriting | Broken file references fail gradually and read as flaky bugs | | 8 | Automations and scheduled jobs | Often absent from exports entirely, must be rebuilt from observed behaviour | | 9 | Monitoring and rollback | After cutover you cannot see what you did not instrument | | 10 | Verification against real accounts | The only step that proves the previous nine worked | The most common reordering mistake is doing the component and interface work first, because it is visible, satisfying and produces something to show. It also produces a large body of code that cannot be tested, which converts a sequencing problem into a debugging problem at the worst possible time. The second most common is treating monitoring as a post-launch task. It is the only step whose value is entirely destroyed by being late.

A badly executed migration does not crash. It produces an app that looks completely finished, right up until a customer sees someone else's data, an automation stops running without anyone noticing, or a returning user cannot log in. That framing comes from EscapeBase44, a vendor selling Base44 migrations, and it is worth taking seriously despite the commercial interest because it names something the loud-failure model misses. Teams prepare for the migration that breaks visibly on cutover day. Crashes get fixed within the hour, because everyone can see them and everyone knows what to do. The migration that hurts is the one where every page renders, every button responds and the demo goes perfectly. The row-level security policy that did not survive the schema migration returns data without complaint. The scheduled job that was never rebuilt produces no error, because a job that does not exist cannot fail. The storage URL still pointing at the old platform keeps working for another six weeks until the subscription lapses. This is exactly why the sequence ends where it does. Steps nine and ten are the only two that exist to detect problems rather than to create the working system, and they are the two that get cut when a migration runs late. Cutting them does not make the migration faster. It moves the discovery of the defects from your test environment to your customers, and it removes the instrumentation that would have told you which defect it was. If you take one thing from the ordering: the last two steps are not the wrap-up. They are the part that determines whether the first eight actually worked.

Why does auth come before the database? Because auth determines whether anything else is testable. You can migrate a schema and have no way to confirm the application reads from it correctly, since every authenticated route is unreachable. Auth is also the step every practitioner source names as the largest time sink, so front-loading it means the biggest unknown is resolved while there is still schedule left to absorb it. Can I skip the security audit if the app is small and private? We would not. Escape's October 2025 scan found 2,038 highly critical vulnerabilities across 5,600 applications, and a large share were configuration issues rather than exotic exploits: tables without row-level security, secrets in client bundles, functions callable with a public key. The audit is a day of enumeration, and it changes the migration plan when it finds something. Do I really need to rotate secrets rather than copy them? Yes. AI tools frequently hardcode keys pasted into prompts, and Escape found over 400 exposed secrets in publicly available vibe-coded applications. Anything that has lived in a generated codebase should be treated as public. Rotation also forces a full credential inventory, which usually surfaces at least one integration nobody remembered. How long does this sequence take? There is no defensible general answer. The timelines circulating publicly, typically three to five days for an experienced developer on a straightforward Lovable migration, come from agencies selling that exact service and should be read as marketing. The honest determinant is your step one inventory: the number of auth providers, buckets, automations and integrations, not the number of screens. What happens to my users' passwords? They do not travel. Lovable's own documentation confirms passwords cannot be exported and a reset flow must be triggered, and Base44's private authentication records have the same constraint. Plan the reset communication in advance so it arrives when users expect it, rather than landing unannounced and reading as a phishing attempt.