Back to Blog
team@tinypod.app

Server Migration: Moving Self-Hosted Apps to a New Server

Upgrading servers? Moving providers? Here's how to migrate your self-hosted apps with minimal downtime.

migrationserversinfrastructuredevops

Why Migrate?


  • Upgrading to a bigger server
  • Switching hosting providers
  • Moving to a different region
  • Server hardware is aging
  • Better pricing elsewhere

    • Migration Strategy


    Phase 1: Prepare (1-2 days before)


    1. Lower DNS TTL to 300 seconds (5 minutes)

    2. Document everything on the current server:

  • Running containers and their configurations
  • Environment variables
  • Volumes and data locations
  • Caddy/Nginx configuration
  • Cron jobs
  • Custom scripts

    • 3. Set up the new server with base configuration


    Phase 2: Transfer (Migration day)


    1. Stop applications that require consistency (databases)

    2. Create final backup of all data

    3. Transfer data to new server:

  • rsync for file data (fastest for large transfers)
  • pg_dump/mysqldump for databases
  • Restic restore for backup-based migration

    • 4. Start applications on new server

    5. Verify everything works


    Phase 3: Cutover


    1. Update DNS to point to new server IP

    2. Wait for DNS propagation (with TTL at 300s, this is fast)

    3. Monitor new server for issues

    4. Keep old server running for 48 hours as fallback


    Phase 4: Cleanup


    1. Restore DNS TTL to normal (3600-86400)

    2. Verify all traffic goes to new server

    3. Final backup of old server

    4. Decommission old server


    Data Transfer Methods


    rsync (Best for files)

    rsync -avz --progress /data/ user@newserver:/data/


    Resumable, efficient, preserves permissions.


    Database Dump/Restore

    pg_dump mydb | ssh user@newserver psql mydb


    Consistent point-in-time copy.


    Restic (Best for full migration)

    Back up on old server, restore on new server.


    Minimizing Downtime


    Pre-sync

    rsync data before the migration window. On migration day, only the delta needs to transfer.


    Parallel Running

    Run apps on both servers. Use DNS to gradually shift traffic.


    Database Replication

    Set up replication from old to new. Promote new as primary during cutover.


    Common Mistakes


  • Forgetting to lower DNS TTL in advance
  • Not testing the new server before DNS cutover
  • Forgetting cron jobs or scheduled tasks
  • Missing environment variables
  • Not keeping the old server as fallback

    • With TinyPod, migration is simplified: export your configuration, deploy on a new server, restore data from backups.