Application Migration Checklist: 20 Essential Checkpoints

Why You Need a Migration Checklist

Migrating an application from one server to another involves dozens of small details. Forgetting a single one can mean a broken application or lost data. The following checklist covers every aspect of migration, from infrastructure to DNS, ensuring nothing gets overlooked.

Print it out, check off each item, and do not begin the switchover until every step is complete.

Phase 1: Pre-Migration (At Least One Week Before)

Infrastructure

• New server provisioned with required specifications (CPU, RAM, SSD)
• Operating system installed and updated with latest security patches
• Firewall configured with the same rules as the old server
• Fail2ban or similar protection tool enabled
• SSH configured (key-based authentication, custom port)
• Timezone set correctly (Asia/Riyadh for Saudi servers)
• NTP enabled for time synchronization

Software Stack

• Same programming language version (PHP 8.3, Python 3.12, Node 20, etc.)
• Same database version (MySQL 8.0, PostgreSQL 16, etc.)
• Same web server version (Nginx 1.24, Apache 2.4, etc.)
• All required extensions and libraries installed
• Composer / npm / pip dependencies installed
• Redis or Memcached if the application uses them
• PHP settings (php.ini): memory_limit, upload_max_filesize, max_execution_time

Application

• Code deployed to the new server (via Git or rsync)
• Configuration file (.env) updated with new server details
• Storage directories (storage/uploads) have correct permissions
• Cache directory is empty and writable
• Logs directory is empty and writable

Phase 2: Data

Database

• Full backup of the old database taken
• Data imported on the new server
• Row counts compared in all major tables
• Critical queries tested and verified
• Indexes and foreign keys verified
• Stored procedures and views confirmed working
• User permissions assigned correctly

Files

• All user files transferred (uploads, media, documents)
• File counts and sizes verified
• File and directory permissions confirmed
• Temporary files transferred if necessary

Phase 3: Services and Integrations

System Services

• Cron jobs: all scheduled tasks copied
• Supervisor: background processes configured (Queue Workers, WebSocket)
• Logrotate: log rotation configured
• Automated backup configured and tested

External Integrations

• Payment gateways: IP address whitelist updated
• Notification services: webhook URLs updated if needed
• External APIs: API keys verified working from the new server
• Email services: SPF and DKIM records updated with new IP address
• CDN: origin server address updated

Phase 4: Security

• SSL certificates installed and working
• HTTP to HTTPS redirect enabled
• Security headers configured (HSTS, CSP, X-Frame-Options)
• Default passwords changed
• Unused services disabled
• Unnecessary ports closed

Phase 5: DNS and Switchover

• TTL lowered 48 hours before the switchover
• New DNS records prepared (A, AAAA, MX, CNAME, TXT)
• DNS switch executed during lowest usage period
• DNS propagation monitored via tools like whatsmydns.net
• Old server kept running for 48 hours after the switch

Phase 6: Post-Switchover

• All main pages tested
• Login and permissions tested
• File upload and download tested
• Forms and email delivery tested
• Payment flows tested (in sandbox mode)
• Logs monitored for errors
• Application performance and response times verified
• Team notified of successful migration

Common Application Migration Mistakes

From real-world experience, these are the most frequently repeated mistakes during application migration:

• PHP version mismatch: The application runs on PHP 8.1 on the old server but you installed PHP 8.3 on the new one. Some functions changed behavior or were deprecated. Solution: match the exact version or test compatibility in advance
• Directory permissions: The application works but file uploads fail because the storage directory lacks write permissions. Solution: chown -R www-data:www-data storage
• Stale .env file: Forgot to update database credentials or API keys in the new .env file
• Missing queue workers: The application works but notifications and emails are not sent because queue workers are not running
• Different PHP settings: memory_limit or max_execution_time differs from the old server configuration
• Cache not cleared: Application shows stale data because cache was not flushed after migration

Automating Migration: Is It Worth It?

If you are migrating a single application once, automation is unnecessary. But if you manage multiple applications or expect future migrations, automating the process saves time and reduces errors:

• Ansible: Write a Playbook that fully provisions the new server (OS, software, security)
• Shell Scripts: A single script that transfers the database and files, then verifies integrity
• CI/CD Pipeline: If you use GitHub Actions or GitLab CI, add an automated deploy stage

The investment in automation pays off with every future migration. A process that took 8 hours manually becomes 30 minutes at the push of a button.

Migration Support from CLOUD

CLOUD (cloud.net.sa) provides free technical guidance sessions for clients' developers during migration. If you have a custom system (ERP, CRM, or internal application), our team helps your developer with planning and execution. Your developer handles the process while we provide technical direction at every stage.

A successful migration starts with a comprehensive checklist. Take your time in preparation and do not rush the switchover until you are certain every item is complete.

--- ### Get Started Want to try it yourself? Choose the right hosting plan or build your custom server with the specs you need.