Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.nextlovable.com/llms.txt

Use this file to discover all available pages before exploring further.

​
What’s Included

Every component of your Lovable backend is migrated to your own Supabase project. Here’s the complete breakdown.

​
Database Migration

All database objects recreated:
  • Tables (all 370 of them, if that’s your case)
  • Columns with correct data types
  • Primary keys
  • Foreign key relationships
  • Unique constraints
  • Check constraints
  • Default values
  • Auto-increment sequences
What stays identical:
  • Table names
  • Column names
  • Data types
  • Relationships
What we validate:
  • Row counts match
  • Foreign keys resolve correctly
  • Constraints are enforced
Data transferred with validation:
  • All rows migrated
  • Binary data preserved (images, files metadata)
  • JSON/JSONB fields intact
  • Arrays maintained
  • Timestamps converted correctly
  • UUIDs preserved
Validation process:
  • Row count verification
  • Sample data checks
  • Relationship integrity tests
  • Constraint validation
Complex types handled correctly:
  • uuid → Preserved
  • timestamp with time zone → Maintained
  • json / jsonb → Intact
  • Arrays (text[], int[]) → Preserved
  • Custom enums → Recreated
  • geometry (PostGIS) → Migrated with extension
Database performance preserved:
  • B-tree indexes
  • GIN indexes (for JSON/text search)
  • GiST indexes (for PostGIS)
  • Composite indexes
  • Partial indexes
  • Index names maintained

​
Row Level Security (RLS)

All Policies Migrated

Every RLS policy from your Lovable database is ported to your new Supabase project.

​
What Gets Ported

Complete policy recreation:
  • Policy names
  • Target tables
  • Operation types (SELECT, INSERT, UPDATE, DELETE)
  • Using expressions (the USING clause)
  • With check expressions (the WITH CHECK clause)
  • Policy roles
-- Example policy that gets migrated
CREATE POLICY "Users can only see their own data" 
ON public.profiles 
FOR SELECT 
USING (auth.uid() = user_id);
Custom functions referenced in policies:
  • auth.uid() calls
  • auth.role() references
  • Custom security functions
  • Helper functions for complex logic
We verify every policy works:
  • Test queries as different users
  • Verify access restrictions
  • Check insert/update permissions
  • Validate delete protections
  • Document any edge cases

​
Authentication Migration

Important: User sessions cannot be migrated. Password resets required.

​
What Transfers

Account metadata migrated:
  • User IDs (UUIDs preserved)
  • Email addresses
  • Email confirmation status
  • Phone numbers (if used)
  • User metadata (custom fields)
  • Account creation timestamps
  • Last sign-in timestamps
  • OAuth provider identities
What doesn’t transfer:
  • Passwords (hashed, cannot be decrypted)
  • Current sessions
  • Refresh tokens
  • MFA settings (must be reconfigured)
Social auth preserved:
  • Google OAuth links
  • GitHub connections
  • Apple sign-in
  • Any other configured providers
What we do:
  • Recreate OAuth app configurations
  • Update callback URLs
  • Test provider connections
  • Verify identity linking
Seamless transition strategy:
  • Pre-migration email to users
  • Post-migration reset trigger
  • Magic link option for immediate access
  • Clear communication templates

​
Edge Functions

Serverless functions transferred:
  • Function code
  • Environment variables
  • Secrets/keys
  • Import maps
  • Dependencies
What we handle:
  • Code extraction
  • Dependency resolution
  • Environment setup
  • Deployment to your project
  • Testing and validation
Database triggers preserved:
  • Insert triggers
  • Update triggers
  • Delete triggers
  • Function bindings
  • Trigger conditions

​
Database Functions

Custom functions migrated:
  • Function definitions
  • Parameters and return types
  • PL/pgSQL logic
  • SQL functions
  • Trigger functions
-- Example function that gets migrated
CREATE OR REPLACE FUNCTION update_updated_at_column()
RETURNS TRIGGER AS $$
BEGIN
    NEW.updated_at = NOW();
    RETURN NEW;
END;
$$ language 'plpgsql';
PostgreSQL extensions:
  • uuid-ossp (UUID generation)
  • pgcrypto (cryptographic functions)
  • postgis (geographic data)
  • pg_trgm (trigram matching)
  • Any other enabled extensions

​
Realtime Subscriptions

Realtime Configuration

  • Publication settings
  • Table subscriptions
  • Event filters
  • Broadcast configuration

Client Configuration

  • Channel setup
  • Event handlers
  • Reconnection logic
  • Filter policies

​
Post-Migration Deliverables

After migration completes, you receive:
  • Migration Report: Complete audit of what was migrated
  • Schema Documentation: ER diagrams and table descriptions
  • RLS Policy Summary: All security rules documented
  • Connection Strings: Database, API URLs
  • Environment Variables: Complete .env file for your app
  • Testing Results: Validation that everything works
  • User Communication Templates: Password reset emails
  • Rollback Plan: Instructions if you need to revert

​
What’s NOT Included

Be aware of these limitations:
Cannot be migrated (hashed, one-way encryption). Workaround: Password reset flow
Current user sessions don’t transfer. Workaround: Users sign in again
Any proprietary Lovable services. Workaround: Replace with standard alternatives
External services not part of Supabase. Workaround: Migrate separately or keep separate

​
Validation Checklist

We verify every component:
ComponentValidation Method
TablesRow count comparison
DataSample verification
RelationshipsForeign key checks
RLS PoliciesPermission testing
Auth UsersAccount verification
Edge FunctionsExecution tests
FunctionsOutput validation

​
Timeline

Typical migration timeline:
  • Small app (10-50 tables): 1-2 days
  • Medium app (50-200 tables): 2-3 days
  • Large app (200+ tables): 3-5 days
  • Complex app (370+ tables): 5-7 days
Includes: discovery, migration, testing, and handoff.
Ready to start? Set up your Supabase project or learn why this costs 3 credits.