The Two-Week Migration Plan: A Realistic Timeline Nobody Tells You

Days 1–2: Provision Your Server and Deployment Pipeline

Secure a virtual private server from Hetzner, DigitalOcean, or Vultr. Expect to pay between $5 and $20 monthly for a server that handles most early-stage applications.

Install a deployment platform like Coolify—think of it as your own private Vercel, running on hardware with your name on the lease. Point your domain at the new server: one DNS record, five minutes. Grab SSL certificates through Let's Encrypt, another fifteen minutes once you know the commands.

Test deployment with a simple static page before touching production code. Push a change, watch it go live. If this step drags past an hour, stop and troubleshoot. Every subsequent step depends on reliable deployments.

Days 2–4: Export Authentication Records and Configure Your New Provider

Export user records from your current authentication provider in JSON or CSV. Most providers bury this option three menus deep, but it exists.

Deploy self-hosted Supabase Auth or Keycloak on your new infrastructure. Map every authentication flow in your application: email login, OAuth connections, password reset sequences, session refresh logic. You will likely discover flows you forgot existed.

Implement the new provider in staging. Test each flow with real credentials before proceeding. A user who cannot log in after migration becomes a former user.

Days 3–5: Migrate Database and File Storage to Self-Hosted Systems

Export all data using your provider's export tools. If you are moving from Firestore or a similar document database, you will convert document structures to relational schemas—like translating a filing cabinet's folders into spreadsheet columns. This conversion typically surfaces data inconsistencies that AI-generated code created and never caught. You might find user records with email fields containing phone numbers, or timestamps stored as strings in three different formats.

Deploy self-hosted Supabase PostgreSQL with row-level security configured for your application's access patterns. Move files from managed storage like Firebase Storage or S3 to MinIO or Supabase Storage on your server.

Set up automated daily backups for both database and files, storing copies on a separate provider. Your backup should survive the same disaster that takes down your primary server.

Days 4–7: Deploy Your LLM Gateway with Local Fallback

Install LiteLLM as a unified gateway—a switchboard operator that routes your AI requests to whichever provider is available. One API for your code, multiple providers behind the scenes.

Configure credentials for OpenAI, Anthropic, and any other services your application uses. Set up Ollama with open-source models like Llama or Mistral to handle requests when commercial providers go down—or when processing sensitive data that should not leave your infrastructure.

Update application code to route all AI requests through your gateway instead of calling providers directly. Test failover by temporarily disabling your primary provider's credentials and watching requests route elsewhere.

Days 8–10: Connect All Systems in Staging

Wire authentication to your new database so user sessions persist correctly. Connect application code to your self-hosted file storage endpoints. Route AI features through your LLM gateway.

Test every user-facing flow systematically: registration, login, core features, file uploads, AI interactions, logout. Pay particular attention to error states. AI-generated code might display a loading spinner forever when the API returns a 500 error, because no one wrote the catch block.

Create a checklist of twenty to thirty specific user actions and verify each one works. Document any failures with screenshots and error messages.

Days 10–12: Execute Production Cutover in Sequence

Schedule migration during your lowest-traffic window—typically early morning on a weekday. Notify users twenty-four hours in advance.

Execute the cutover in dependency order: DNS first, then authentication endpoints, then database connections, then LLM routing. Each step should be independently reversible so you can roll back a single component without unwinding everything.

Keep old infrastructure running in read-only mode for forty-eight hours. Monitor error rates, authentication failures, and API response times continuously. Set your phone to alert you on any spike.

Days 13–14: Validate Migration and Establish Operations

Spot-check ten random user records against your original export. Verify authentication works across all client applications including mobile apps and third-party integrations. Test AI features under typical load.

Set up monitoring with Uptime Kuma or Grafana to alert you when services go down. Document your infrastructure architecture so you can rebuild it if needed. Create runbooks for the three most likely scenarios: scaling during traffic spikes, restoring from backup after data loss, switching LLM providers during an outage.