Lovable enables rapid prototyping by abstracting backend complexity through managed services like Supabase and built-in AI gateways. However, this convenience introduces architectural constraints when applications need to scale, integrate, or meet enterprise security requirements.
This article outlines a principled migration path from a Lovable app to a cloud-native architecture. The focus is not on tooling, but on structure: introducing a service layer, mapping managed primitives to cloud equivalents, and shifting from a 2-tier to a 3-tier architecture with an explicit backend API.
Using the Plant Pal example, we show how to incrementally migrate without rewriting the application by isolating change to a single service boundary. The key idea is simple: when designed correctly, migration becomes a controlled architectural transition rather than a disruptive rebuild.
And how to set yourself up for migration from Day 1
Lovable lets you go from idea to working application in minutes. But as applications grow, so do concerns about maintainability, ownership, and security. At some point, what was perfect for prototyping starts holding you back. And when that moment arrives, chances are it’s already too late — and the “migration” turns into a rewrite.
This blog post is Part 2 of a two-part technical series. Part 1 dissected the anatomy of a Lovable app (and where that setup starts to clash with enterprise constraints). This post focuses on how to migrate any Lovable application to the cloud. Along the way, I’ll share a few tips you can adopt from Day 1 to reduce your migration pains later.
❌ This is not a step-by-step Terraform tutorial or a guide to setting up VPCs, load balancers, and production-grade CI/CD.
✅ Instead, the focus is on the architectural decisions and mental model behind a clean migration path. The accompanying repository contains the full implementation details for those who want to go deeper.
You can find the Plant Pal codebase here, containing both the original Lovable app and the migrated Azure version.
In Part 1, we introduced Plant Pal: a small app where you upload a plant photo, get an AI-powered health check, and view your analysis history.
Under the hood, Plant Pal is built on four core backend primitives:
The first three are Supabase-managed; the AI Gateway is Lovable-managed.
The architecture is “2-tier-ish”: the browser talks directly to Supabase Storage and Database using a publishable key and Row Level Security (RLS). Edge Functions handle anything requiring server-side secrets.
Part 1 ended by discussing enterprise constraints like network isolation and CI/CD, which make this setup hard to sustain. This post picks up from there.
In Part 1, Plant Pal looked almost suspiciously “migratable.” All backend calls were isolated in a single service file (plantService.ts), and no React components touched the Supabase backend directly.
GenAI tools like Lovable prioritize speed, often scattering backend calls directly inside UI components (like useEffect hooks) by default. This leads to tight coupling, which creates friction in three key ways:
Key Takeaway: Introduce a service boundary early. Components should call uploadPlantImage() without needing to know how the upload happens. During migration, you can swap the implementation behind that boundary without touching the UI.
To get Lovable to produce this structure consistently, we have added a small set of project rules (via Lovable’s knowledge feature):
src/services/<domain>Service.ts.supabase.* directly.
Concretely, this means we can change the backend all we want, and once finished, we only need to update one file in the frontend.
The first step in migration is to identify your components, then swap each one to it’s cloud equivalent one at a time.
Every cloud has a direct equivalent for every Supabase primitive. That’s not a coincidence — Supabase is built on the same open-source building blocks (PostgreSQL, S3-compatible storage, Deno) that these cloud providers wrap as managed services.
The following table gives a high level overview of the alternatives for each cloud.
However, the migration is a little more than a provider swap. We move from a 2-tier setup (where the browser talks directly to database and storage) to a 3-tier architecture, where all data access flows through a backend API that we control. That architectural shift is the real migration.
Shift: [Browser ➔ Database/Storage] becomes [Browser ➔ API ➔ Database/Storage]
In the Lovable version, the browser communicated directly with Storage and the Database, and we had a single Edge Function for AI orchestration. In the cloud-native version, those direct interactions become explicit API endpoints that we own.
Concretely, the backend grows from one function to three endpoints:
Option 1: Serverless Functions (Azure Functions, AWS Lambda, GCP Functions)
Choose this if:
Option 2: Containers (Azure Container Apps, AWS ECS, GCP Cloud Run)
Choose this if:
Shift: [Public Access] ➔ [Private/Authenticated Access]
In Lovable, storage is often “convenience-first”: buckets are public, and the browser fetches files directly via permanent URLs.
In a cloud-native architecture, we flip the default to security-first. Buckets are private and hidden behind the firewall. The browser no longer has unconditional access; instead, it must request short-lived “signed URLs” from your backend API or stream files through a proxy endpoint. This gives you absolute control over who sees what and for how long.
Shift: [Row Level Security] ➔ [Application Layer Authorization]
In the original Lovable setup, the database was “on the internet,” protected only by Row Level Security (RLS) policies.
In the migrated architecture, the database is no longer reachable by the client. It lives inside a private network, accessible only by your backend API. Because the API is the sole gatekeeper, authorization shifts from the database layer (RLS) to the application layer. The backend validates the user’s identity once at the entry point, then executes queries on their behalf.
Moving to the cloud provides control, but control alone doesn’t equal production-readiness. Use this checklist to bridge the gap from prototype to professional system:
Let’s now take the above method and use it to migrate Plant Pal to Azure.
The very first step in the Azure migration has nothing to do with Azure.
Before touching infrastructure, we export the Lovable project to GitHub and reshape it into a structure that can support infrastructure, backend, and frontend as separate concerns.
Lovable generates a single-project structure: one src/, one package.json, one runtime. That is perfect for prototyping. But once we introduce Terraform, a custom backend, CI/CD, and cloud resources, that flat structure becomes limiting.
So the first migration step is purely structural: we turn the project into a monorepo with three top-level folders: frontend/, backend/, and terraform/ .
The Lovable-generated files are moved to the frontend/folder and we introduce a new root package.json that delegates commands to the frontend.
After restructuring, the repository looks like this:
Crucially, this change is non-breaking. The app still talks to Supabase while we establish clear boundaries for independent deployment pipelines.
With our repository structure ready, we use Terraform to define our Azure resources declaratively.
Your terraform state should never live on a developer’s laptop. Before deploying the app, we establish a Terraform Remote State. We provision a secure, locked storage account in Azure to hold the “brain” of our infrastructure. This prevents accidental conflicts and creates an audit trail for every change.
Once the foundation is secure, we deploy the actual application stack. For Plant Pal, this includes six key Azure resources:
Because both platforms use PostgreSQL, we take the original SQL migrations and execute them against Azure. The only real adjustment needed is removing the RLS policies, as our new API now handles authorization.
Resources are provisioned, and their connection strings are stored in Azure Key Vault. For local development, we inject these via .env files. This replaces Lovable’s implicit secret management with explicit, auditable configuration.
At this stage, the Azure environment is fully provisioned: the infrastructure is live, the database schema runs on Azure, the frontend still works unchanged, and Supabase remains active in parallel.
In other words, we have duplicated the environment — without cutting over yet. By establishing infrastructure first and replacing runtime components only afterwards, we reduce risk and keep the migration controlled and incremental.
With our infrastructure in place, we can now replace the Supabase Edge Function with our own backend.
Each function mirrors the responsibility of its Supabase counterpart — but now runs inside our own cloud environment.
Architecturally, this is the key moment of the migration!
We move from Browser → Database / Storage (public)
to Browser → Backend API → Database / Storage (private)
Because we introduced a service layer in Section 2, only a single file required modification: src/services/plantService.ts. We simply swapped Supabase SDK calls for standard fetch() calls.
From the UI’s perspective, nothing happened! This is the direct payoff of introducing a service boundary early! In practical terms, this reduces risk dramatically. UI regressions are unlikely because the surface area of change is tiny.
So .. was it worth it?
Starting with Lovable gives you speed through trust. You describe what you want, iterate quickly on UX, and within hours you have a working application. For design sprints or early product validation, that speed is hard to beat. If you are building an isolated app with limited security constraints, staying on Lovable Cloud is perfectly reasonable. We have done this ourselves for simple workflows where the real value comes from reduced operational overhead, not complex infrastructure.
But most companies do not operate in isolation. They have defined multi-cloud strategies, security policies, and identity standards. In that context, the win is combining both worlds:
At ML6, this middle ground has proven to be the most pragmatic approach. We use Lovable as a product accelerator to define the “What,” but we move to a managed cloud environment for the “How” — ensuring long-term maintainability and security.
Key Takeaway: Lovable is a product accelerator, not the final production runtime. If you treat it as the first phase of a structured migration path, you can move fast without ever losing control.