How to Move a SaaS from a VPS to a Managed Platform Safely

How to Move a SaaS from a VPS to a Managed Platform Safely

Moving your SaaS from a VPS (where you manage the server) to a managed PaaS (where the platform manages the server) eliminates the maintenance burden and gives you AI-native features. But the migration itself is risky: if done wrong, you can lose data, break your app, or cause downtime. This article is the safe migration guide for SaaS founders who want to move without disrupting their customers.

The direct answer is that a safe migration has six steps: prepare (inventory your resources), deploy (to the new platform without cutting over), migrate data (database, files), test (verify everything works), switch DNS (point your domain to the new platform), and decommission (shut down the VPS). The key is to run both platforms in parallel during the transition, so you can roll back if something goes wrong. For more on platform selection, see our article on how to choose a PaaS for a full-stack SaaS.

Step 1: Prepare (Inventory Your Resources)

Before migrating, inventory everything on your VPS:

• Applications. List all apps running on the VPS (frontend, API, workers).
• Database. What database are you using? Where is it running? What is the connection string?
• Environment variables. List all environment variables (secrets, configuration).
• Custom domains. List all domains and DNS records.
• SSL certificates. List all SSL certificates and their expiration dates.
• Cron jobs. List all scheduled tasks.
• Files. List all user-uploaded files and where they are stored.
• Services. List all external services (Redis, email, search).

Document everything in a migration checklist. For more on inventorying, see our article on the production checklist before your SaaS takes its first customer.

Step 2: Deploy to the New Platform (Without Cutting Over)

Deploy your app to Deployxa without switching DNS:

• Push to GitHub. Ensure your code is in a GitHub repository.

• Connect to Deployxa. In the Deployxa dashboard, connect your repository. The zero-config engine detects your framework and configures the build. For more, see our article on how to launch a SaaS app without a DevOps team.

• Set environment variables. Copy all environment variables from your VPS to the Deployxa dashboard. For more, see our article on a founder's guide to environment variables, secrets, and least privilege.

• Deploy. Click "Deploy" and verify the build succeeds and the health check passes. The app is now running on Deployxa, accessible at a Deployxa subdomain (e.g., my-app.deployxa.app), but not yet at your custom domain.

• Verify the app. Visit the Deployxa URL and verify the app loads, the health check passes, and the database is connected.

Step 3: Migrate Data

Migrate your data from the VPS to the new platform:

• Database migration. If your database is on the VPS, migrate it to a managed database provider (e.g., Supabase, Neon). Use pg_dump to export the database and pg_restore to import it:

# Export from VPS
pg_dump "postgresql://user:pass@vps-host:5432/mydb" -F c -f backup.dump

# Import to managed database
pg_restore -d "postgresql://user:pass@managed-host:5432/mydb" backup.dump

Update the DATABASE_URL environment variable in the Deployxa dashboard to point to the new database. For more on database migration, see our article on how to rehearse a database restore before you need one.

• File migration. If user-uploaded files are on the VPS, migrate them to external storage (e.g., S3, Cloudflare R2). Use rsync or rclone to copy the files:

rclone copy /var/www/uploads remote:my-bucket/uploads

Update your app's storage configuration to point to the new storage.

Step 4: Test (Verify Everything Works)

Test the app on the Deployxa URL (not your custom domain yet):

• Test the complete customer journey. Sign up, log in, process a payment, create content, upload a file.
• Test the health check. Verify the /health endpoint returns 200.
• Test the rollback. Verify you can roll back to the previous release. For more on rollback, see our article on what SaaS founders should know about deployment rollback and backups.
• Test the backup restore. Verify you can restore the database from a backup. For more on backup testing, see our article on how to rehearse a database restore.
• Test cron jobs. If you had cron jobs on the VPS, verify they are running on Deployxa (via node-cron or similar). For more on cron jobs, see our article on why AI-generated cron jobs don't run on serverless.

Step 5: Switch DNS

Once everything is tested and working on the Deployxa URL, switch your DNS to point to Deployxa:

• Add your custom domain to Deployxa. In the Deployxa dashboard, add your custom domain. The platform provides a CNAME record.

• Update DNS. In your DNS provider, update the CNAME record to point to Deployxa. Use a low TTL (300 seconds) so the propagation is fast. For more on DNS, see our article on how we handle custom domains.

• Wait for propagation. DNS propagation takes 5-60 minutes. Monitor the propagation using dig or a DNS checker.

• Verify. Once DNS propagates, visit https://myapp.com and verify the app loads correctly, the SSL certificate is valid, and the database is connected.

Step 6: Decommission the VPS

Once your app is running on Deployxa and everything works, decommission the VPS:

• Keep the VPS running for 1 week. Do not shut it down immediately. Keep it running as a fallback in case you discover an issue with the Deployxa deployment.

• Monitor for issues. During the transition week, monitor the Deployxa deployment closely (logs, metrics, alerts). If any issues arise that you cannot fix quickly, you can switch DNS back to the VPS. For more on monitoring, see our article on monitoring your SaaS without hiring a DevOps engineer.

• Shut down the VPS. After 1 week with no issues, shut down the VPS. Cancel the VPS subscription. Back up any remaining data (e.g., log files, configuration files) before shutting down.

Common Pitfalls and Troubleshooting

The first pitfall is not testing before switching DNS. If you switch DNS before testing, your customers might see a broken app. The fix is to test on the Deployxa URL first. The second pitfall is not keeping the VPS as a fallback. If you shut down the VPS immediately and discover an issue, you have no fallback. The fix is to keep the VPS running for 1 week. The third pitfall is not migrating all environment variables. If you miss an environment variable, the app might not work correctly. The fix is to inventory all environment variables before migrating. The fourth pitfall is not migrating all data. If you miss user-uploaded files or a Redis cache, the app might lose data. The fix is to inventory all data before migrating. The fifth pitfall is not lowering the DNS TTL before switching. If the TTL is high (e.g., 86400 seconds), the DNS propagation is slow, which means some users see the old app and some see the new app. The fix is to lower the TTL to 300 seconds 24 hours before switching.

Conclusion: Migrate Safely, Not Quickly

Moving from a VPS to a managed PaaS eliminates the maintenance burden and gives you AI-native features, but the migration itself is risky. By following the six-step process (prepare, deploy, migrate data, test, switch DNS, decommission), you can migrate safely without disrupting your customers. The key is to run both platforms in parallel during the transition, so you can roll back if something goes wrong.

Ready to migrate? Deploy your app to Deployxa Drop for a zero-signup proof of concept, then follow the migration guide above. For more, see how to choose a PaaS for a full-stack SaaS and how to estimate deployment costs for a small SaaS. Explore our free developer tools to speed up your workflow.