How to Migrate Your SaaS to a New Platform Without Losing Customers | Deployxa

Migrating your SaaS to a new platform is risky. Here is the founder's guide to migrating without downtime, data loss, or customer churn.

← Back to Dispatch Articles
Engineering Log

How to Migrate Your SaaS to a New Platform Without Losing Customers

Migrating your SaaS to a new platform is risky. Here is the founder's guide to migrating without downtime, data loss, or customer churn.

How to Migrate Your SaaS to a New Platform Without Losing Customers

Key Facts

  • Direct answer: The direct answer is that a safe migration has six steps: inventory (what do you have?), 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 old platform).

  • Step 1: Inventory: Before migrating, inventory everything on your current platform.

  • Step 2: Deploy to the New Platform (Without Cutting Over): Deploy your app to the new platform (e.g., Deployxa) without switching DNS.

  • Step 3: Migrate Data: Migrate your data from the old platform to the new.

  • Step 4: Test (Verify Everything Works): Test the app on the new platform's URL (not your custom domain yet).

Migrating your SaaS to a new platform is one of the riskiest operations you will ever perform. If done wrong, you can lose data, cause downtime, and churn customers. If done right, the migration is invisible to your customers — they do not even notice it happened. This article is the founder's guide to migrating without losing customers.

The direct answer is that a safe migration has six steps: inventory (what do you have?), 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 old platform). The key is to run both platforms in parallel during the transition, so you can roll back if something goes wrong. For more on migration, see our article on how to move a SaaS from a VPS to a managed platform safely.

Step 1: Inventory

Before migrating, inventory everything on your current platform:

  • Applications. List all apps (frontend, API, workers).
  • Database. What database? Where is it? What is the connection string?
  • Environment variables. List all variables (secrets, configuration).
  • Custom domains. List all domains and DNS records.
  • Files. List all user-uploaded files and where they are stored.
  • Cron jobs. List all scheduled tasks.
  • External 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 the new platform (e.g., Deployxa) without switching DNS:

  • Push to GitHub, connect to Deployxa, deploy.
  • Set all environment variables in the Deployxa dashboard.
  • Verify the app loads on the Deployxa URL (e.g., my-app.deployxa.app).
  • Verify the health check passes.

The app is now running on the new platform, but your customers are still using the old platform (because DNS has not been switched). For more, see our article on how to launch a SaaS app without a DevOps team.

Step 3: Migrate Data

Migrate your data from the old platform to the new:

  • Database. Export the database from the old platform (pg_dump), import to the new platform (pg_restore). Update the DATABASE_URL environment variable on the new platform. For more, see our article on how to rehearse a database restore.
  • Files. Migrate user-uploaded files from the old platform's storage to the new platform's storage (or to external storage like S3). Use rsync or rclone.
  • Redis. If you use Redis for caching or job queues, set up a new Redis instance on the new platform. You do not need to migrate cached data (it will be regenerated), but you need to migrate job queue data if there are pending jobs.

Step 4: Test (Verify Everything Works)

Test the app on the new platform's URL (not your custom domain yet):

  • Test the complete customer journey: signup, login, payment, content creation.
  • Test the health check: verify it returns 200.
  • Test the rollback: verify you can roll back on the new platform.
  • Test the backup restore: verify you can restore the database.
  • Test cron jobs: verify scheduled tasks are running.

If anything fails, fix it before proceeding. Do not switch DNS until everything works on the new platform.

Step 5: Switch DNS

Once everything is tested and working on the new platform, switch your DNS:

  • Add your custom domain to the new platform (Deployxa dashboard).
  • Update DNS: lower the TTL to 300 seconds 24 hours before switching, then change the CNAME/A record to point to the new platform.
  • Wait for propagation (5-60 minutes).
  • Verify: visit https://myapp.com and verify the app loads from the new platform.

For more on DNS, see our article on the SaaS founder's guide to custom domains and SSL.

Step 6: Decommission the Old Platform

Once your app is running on the new platform and everything works:

  • Keep the old platform running for 1 week. Do not shut it down immediately. Keep it as a fallback.
  • Monitor the new platform closely. Watch logs, metrics, and alerts. If any issues arise, switch DNS back to the old platform.
  • Communicate with customers. If the migration causes any visible issues (e.g., a brief downtime, a missing feature), communicate openly via your status page and email.
  • Shut down the old platform. After 1 week with no issues, shut down the old platform. Back up any remaining data before shutting down.

For more on monitoring, see our article on monitoring your SaaS without hiring a DevOps engineer.

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 new platform's URL first.

The second pitfall is not keeping the old platform as a fallback. If you shut down the old platform immediately and discover an issue, you have no fallback. The fix is to keep the old platform running for 1 week.

The third 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 fourth pitfall is not lowering the DNS TTL. If the TTL is high (86400 seconds), the DNS propagation is slow, which means some customers see the old app and some see the new app. The fix is to lower the TTL to 300 seconds 24 hours before switching.

The fifth pitfall is migrating during peak hours. If you migrate when traffic is high, any issue affects more customers. The fix is to migrate during off-peak hours (e.g., 2 AM on a weekend).

Conclusion: Migrate Safely, Not Quickly

Migrating your SaaS to a new platform is risky, but it is manageable with the right process. By following the six-step process (inventory, deploy, migrate data, test, switch DNS, decommission), you can migrate without downtime, data loss, or customer churn. 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 move a SaaS from a VPS to a managed platform safely and how to estimate deployment costs for a small SaaS. Explore our free developer tools to speed up your workflow.

Ready to deploy with Deployxa?

Deploy your apps globally with automatic SSL and AI diagnostics.

Start Free Now