Step-by-Step Checklist to Move a Laravel App to a New Hosting Provider

Migrating a Laravel application requires careful planning to avoid downtime, data loss, and configuration errors. This guide outlines a practical checklist for migrating a Laravel application to a new hosting provider, covering backups, environment configuration, dependency management, database migration, and verification steps.

Preparing to move: inventory and backups

Catalog application components

Produce an inventory of the Laravel application components, including PHP version requirements, Composer packages, queued jobs, scheduled tasks (cron), environment variables, SSL certificates, session and cache drivers, and any external services such as object storage or email providers. Record database type and extensions (MySQL, PostgreSQL, Redis, etc.).

Create reliable backups

Take full backups before initiating any migration steps. Back up the application source code (or export from version control), database dumps, and persistent file storage (public/uploads, storage directories). Store backups in multiple locations and verify backups by restoring to a test environment.

Migrating a Laravel Application: step-by-step checklist

Provision the new environment

Choose a host that supports the required PHP version and extensions. Install and configure web server software (Nginx or Apache), PHP-FPM, and any necessary system packages. For managed platforms, verify runtime and buildpack compatibility. Configure file system permissions for the Laravel storage and bootstrap/cache directories.

Install dependencies and deploy code

Deploy the application code to the new host using a supported method: Git, CI/CD pipeline, or file transfer. Run Composer to install PHP dependencies and run any frontend build steps (npm, yarn, mix). Ensure composer install is executed with appropriate flags for production (for example, --no-dev and optimized autoloader).

Configure environment and secrets

Recreate environment variables (APP_KEY, DB_* settings, MAIL_*, and third-party API keys) on the new host using the provider's secret management or environment configuration. Generate or import the APP_KEY before running migrations. Avoid committing secrets to source control.

Database migration and synchronization

Prepare the target database by creating the correct user and privileges. Restore a database dump or use replication to synchronize data. For minimal downtime, consider setting up replication from the old database to the new one and switching connections at cutover. Run Laravel migrations and seeders as needed, and verify indexes and extensions.

File storage, sessions, and cache

Copy persistent storage such as user uploads to the new host or to a shared object storage service. If sessions or cache rely on Redis or Memcached, provision equivalent services and update the environment configuration. Verify queue workers are configured and use the correct queue connection and supervisor configuration.

Testing, cutover, and verification

Staging verification

Test the application on a staging or temporary domain. Verify user flows, file uploads, scheduled tasks, email delivery, authentication, payment processing, and background jobs. Use automated tests where available and perform manual smoke tests for critical paths.

DNS and SSL cutover

Plan the DNS cutover during a low-traffic window. Reduce TTL values in advance to speed propagation. Update DNS records to point to the new host and verify that SSL certificates are in place (use automated provisioning with Let's Encrypt or import existing certificates). Monitor for errors after propagation.

Monitoring and rollback plan

Enable logging and monitoring (application logs, server metrics, error tracking). Keep the rollback plan ready: this can include restoring DNS to the previous host, re-attaching traffic to the old database, or restoring backups. Keep stakeholders and on-call personnel informed of the migration window and expected post-migration checks.

Post-migration tasks and optimization

Performance tuning

After migration, tune PHP-FPM, OPCache, database configuration, and web server settings for the new environment. Rebuild Laravel caches (config:cache, route:cache, view:clear) and warm caches to reduce first-request latency.

Security and compliance checks

Verify file and directory permissions, enforce HTTPS, rotate any keys or certificates as appropriate, and confirm that backups and retention policies meet organizational requirements. Refer to OWASP guidelines and platform compliance documentation for best practices.

Resources

Official framework and platform documentation can assist with environment-specific configuration; see the Laravel documentation for framework-specific guidance: Laravel documentation. Also consult PHP.net for runtime details, Composer documentation for dependency management, and database vendor guides for migration specifics.

FAQ

How long does migrating a Laravel application typically take?

Migration duration depends on application size, data volume, and complexity of services. Small apps with simple databases may take a few hours, while large systems with terabytes of data, complex queues, and external integrations can require days of preparation and staged cutover. Timing should include verification and fallback planning.

What are common causes of downtime during migration?

Downtime often results from incomplete environment replication, missing environment variables or secrets, incompatible PHP or extension versions, database synchronization lag, and DNS propagation delays. Thorough staging tests and a rollback plan reduce the risk.

Is it necessary to change the APP_KEY when migrating?

Do not change APP_KEY during migration unless re-encrypting stored data. The APP_KEY must remain consistent to allow existing encrypted data and sessions to decrypt correctly. If generating a new key, ensure data that relies on the old key is re-encrypted beforehand.

How should queued jobs and scheduled tasks be handled?

Stop workers on the source host before final database sync to prevent jobs from running twice. Configure supervisor or the host's job management system on the new host and ensure schedules (cron entries) are set. Verify that queue connections and retry settings are correctly configured.

What is the best way to test the migrated application?

Use a combination of automated tests (unit and integration), manual smoke testing of key user journeys, and synthetic monitoring to validate the production behavior. Test email delivery, file uploads, authentication, payments, and background processing under expected load patterns.