Vercel to Managed VPS: A Migration Path That Won't Break Prod

Your Vercel bill was fine at launch. Then traffic grew, you added a few background jobs, and the invoice now mixes seat costs, function invocations, bandwidth, image optimization and edge requests. For a founder or CTO at an Indian SMB, the problem is not the platform itself; it is the feeling that costs scale faster than revenue, and that you cannot run a WhatsApp session, a long PDF generator, or a nightly reconciliation job without fighting the runtime. The obvious answer is a managed VPS. The hard part is moving without breaking production.

The bill is not the only line item

Vercel is a managed platform, and you pay for convenience. A Pro seat is $20 per user per month. On top of that, usage for bandwidth, serverless invocations, edge requests, image optimization and cron adds up. For a small B2B portal, that might still be $30-60 a month. For one with steady API traffic, file uploads and scheduled jobs, it can cross $150-300. These are illustrative ranges, not a quote.

A managed VPS is a rented Linux machine. A 2 vCPU, 4 GB RAM, 80 GB NVMe instance in Mumbai from DigitalOcean, Linode, AWS Lightsail or E2E Networks typically costs ₹1,200-2,500 per month. Add backups, S3-compatible object storage and uptime monitoring, and you might land at ₹2,000-4,000 per month. The catch is ownership: patching, TLS renewal, database backups, alerting, deployment scripts and incident response are yours.

In our experience, if you do not have an ops person, budget 4-8 hours a month for maintenance. At ₹1,000-2,000 per hour, that is ₹4,000-16,000 of opportunity cost. Also check how your vendor bills GST, whether TDS under Section 195 applies to a foreign payment, and what forex markup your card adds. A cheaper monthly invoice can be more expensive after tax and time.

What breaks in a lift-and-shift

Moving a Vercel app to a VPS is rarely simple. These are the usual failures:

• Stateless assumptions. Serverless functions expect short, stateless runs. Persistent WebSockets, WhatsApp sessions, long PDF jobs and in-memory queues need workers, a process manager and a queue like Redis or RabbitMQ.
• Ephemeral filesystem. Local uploads, SQLite files, session files and generated reports vanish on redeploy. Move them to S3-compatible storage or a mounted block volume.
• Platform features. Cron, ISR, image optimization and edge middleware have replacements: systemd timers or cron, a build step, Sharp or Thumbor, and Nginx rules. Map every one.
• Database connections. Serverless functions open and close connections differently from a long-running Node or Python process. Add PgBouncer or a connection pool before you cut over.
• DNS and TLS. Lower your TTL to 60 seconds at least 24 hours before cutover. Keep the Vercel deployment live. Know which A/CNAME record moves and how fast you can revert.
• Logs and alerts. Vercel's dashboard disappears. You need structured logs, metrics and an uptime check before production traffic arrives.

A staged migration that keeps production live

The safest migration is boring and reversible. Do it in stages, and never move DNS until the new stack has served real traffic from a test hostname.

• Baseline and size. Export two weeks of Vercel usage: requests, invocations, bandwidth, cron runs, image optimizations. Map that to a VPS. Example: 250,000 monthly requests, 2 million function calls, 25 GB bandwidth, 3 cron jobs and one Postgres database. On Vercel Pro, one seat plus usage might be $50-90 per month (roughly ₹4,200-7,600). A 4 vCPU, 8 GB, 160 GB NVMe VPS in Mumbai might be ₹2,500-4,000, plus ₹400 for backups and ₹200 for object storage. That is ₹3,100-4,600. Add 6 hours of maintenance at ₹1,500 per hour, or ₹9,000, and the VPS is not cheaper yet. At 2 million monthly requests, Vercel usage can cross $200-400, while the same VPS handles it with a bump to 8 vCPU and 16 GB for ₹5,000-8,000. That is the point where self-hosting economics flip.
• Build a shadow stack. Use Docker Compose, Coolify, Dokku or CapRover. Run Nginx or Caddy, Postgres, Redis and your app. Deploy the same commit. Test with a hosts file entry or a Cloudflare Tunnel. Do not touch production DNS.
• Move data safely. Take a logical backup with pg_dump, restore to the VPS, then set up logical replication for the cutover window. Sync uploads with rclone. Run read-only tests and compare row counts. Keep the old database untouched.
• Cut over with a rollback switch. Lower TTL. Switch DNS during a low-traffic window. Watch 5xx rates, p95 latency, database connections and queue depth. Define a rollback trigger: for example, more than 2% errors for 10 minutes, or p95 latency above 2 seconds. If triggered, switch DNS back and investigate.
• Retire the old stack slowly. Keep Vercel running for 7-14 days. Compare logs and costs. Only then cancel the plan and remove old environment variables.

When staying on Vercel is the right call

Self-hosting is not a religion. If your traffic is spiky, if you have no ops capacity, if you rely on preview deployments and edge middleware, or if you need low latency across regions without thinking about it, Vercel's premium can be rational. You are buying velocity.

A managed VPS makes more sense when load is predictable, when you need long-running processes or persistent connections, when data residency under the DPDP Act matters, or when the usage bill has become a board-level line item. It also helps if you already run Docker and Postgres and have someone who can own a runbook.

Where to start

Start with a two-week usage export and a one-page runbook: what runs where, what talks to what, and how you roll back. Then build the shadow stack and test it with real read traffic before you move a single DNS record. If you want a second pair of eyes on that plan, Maysan Labs has migrated B2B portals and internal tools from platform hosts to managed VPS setups; the first step is a clear inventory.