Moving your SaaS off Vercel or AWS to dedicated servers you own

Moving a SaaS off Vercel or AWS to dedicated servers you own is one of those ideas that sounds either obviously right or reckless, depending on who you ask. In practice it is neither. For some products it removes a large, growing bill and a lot of accidental complexity. For others it swaps a managed service that works for operational work nobody on the team wants. This post is about telling the two apart, and about how to do the move carefully when it is the right call.

When moving to dedicated servers makes sense

Dedicated servers from providers such as Hetzner or OVHcloud give you a fixed monthly price for a fixed amount of CPU, memory, disk and, usually, a generous traffic allowance. The model favours some workloads strongly.

It tends to make sense when:

• Usage is steady and predictable. A typical B2B SaaS with daytime traffic and a known number of customers does not need per-request scaling.
• The bill is dominated by usage-based line items. Bandwidth, function invocations, build minutes, preview deployments, managed database instances sized for peak, NAT gateways and data transfer between services add up quietly.
• The architecture is a few services and a database. A web app, an API, a worker, Postgres or MySQL, Redis. That shape moves cleanly.
• Someone will own operations afterwards. That can be an in-house engineer or a monthly management arrangement, but it has to be someone.

When it does not

Be equally honest about the cases where it is a bad idea:

• Spiky or unpredictable load that genuinely needs to scale up and down within minutes.
• Deep use of provider-specific services such as DynamoDB, Lambda-heavy event pipelines, Cloud Spanner or BigQuery. Replacing those often means rewriting code, and that changes the economics completely.
• Small bills. If hosting costs are a minor share of spend, the saving rarely justifies the risk and the effort.
• Compliance requirements tied to a specific provider or region that a dedicated host cannot satisfy.
• No one to own it. Unmanaged servers decay. Patches get missed, disks fill up, backups fail silently.

A good audit will sometimes conclude "stay where you are" or "move only these two services". That is a useful result, not a failure.

Start by reading your invoices

Before any architecture discussion, read your last three invoices line by line. You are looking for where the money actually goes, not where you assume it goes.

1. Group line items by category: compute, database, storage, bandwidth and data transfer, builds and previews, logging and monitoring, and support or plan fees.
2. Separate fixed from usage-based costs. Usage-based items are the ones that grow with your customers and that dedicated servers flatten.
3. Look for surprises. Common ones are cross-zone or egress transfer charges, log ingestion, idle preview environments, oversized database instances and snapshots that were never cleaned up.
4. Note the trend. Three months is the minimum to see whether costs are growing faster than revenue.

Then size the replacement: how many servers, how much RAM and disk, where the database runs and where backups go. Compare like with like, including the time someone will spend running it.

What moves and what stays

A migration does not have to be all or nothing. A hybrid setup is often the best outcome.

If a service cannot move without rewriting application code, it should stay put. A migration project that quietly turns into a rewrite is the most common way these go wrong.

Deploys: keep the git-push workflow

Teams coming from Vercel are used to pushing to a branch and getting a deployment. Losing that is the fastest way to make a migration unpopular, so replace it on day one.

A setup we use is Docker for every service plus a self-hosted deploy tool such as Dokploy, which gives you git-push deploys, environment variables, domains and TLS from a web interface on your own server. Coolify and Kamal are other options in the same space. The important parts are that every service builds from a Dockerfile in the repository, configuration lives in environment variables rather than on the server, and anyone on the team can deploy without SSH access.

Backups, monitoring and hardening

These are the things the managed platform was quietly doing for you. They need to exist before cutover, not after.

• Backups: nightly database dumps to off-site object storage with a different provider or region, encrypted, with a retention policy, and at least one tested restore before go-live. A backup you have never restored is not a backup — see how we run tested backups and restore drills.
• Monitoring: uptime checks from outside your network, plus CPU, memory, disk and database alerts that go to people who will act on them.
• Hardening: firewall with only the needed ports open, key-only SSH, automatic security updates, TLS everywhere and sensible security headers.

The cutover: one weekend, rehearsed rollback

The migration itself should be boring. The way to make it boring is to do almost all the work before the cutover window.

1. Build in parallel. The new environment runs alongside the old one. Nothing changes for users yet.
2. Rehearse the data move. Do a full trial migration of the database, time it, and verify row counts and a sample of records.
3. Lower DNS TTLs a few days ahead, so the switch propagates quickly.
4. Agree one window, usually a weekend, with a clear go or no-go checkpoint.
5. Rehearse the rollback. Write down the exact steps to point traffic back to the old environment, and actually run them once.
6. Keep the old environment warm for a couple of weeks after cutover, untouched, so rolling back is a DNS change rather than a rebuild.
7. Hand over a runbook covering deploys, restores, restarts and who to call.

Here is a clearly hypothetical example of what the decision looks like. A SaaS with a Next.js frontend, a Node API, a worker and Postgres finds, from its invoices, that bandwidth, builds and a peak-sized managed database make up most of its bill. The frontend's static assets stay on a CDN, transactional email stays with its current provider, and the app, API, worker and database move to two dedicated servers with nightly off-site backups. If the same team instead relied on a provider-specific queue and serverless functions throughout, the honest recommendation would be to leave those alone.

Get the numbers before the opinions

Our cloud and infrastructure work is built around exactly this kind of move, and the Cloud Repatriation offer starts with a free audit of your real invoices and architecture, ending in a written plan of what moves, what stays and the risks.