Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Hector-moya's avatar

Migrations in Production

Hi everyone,

I've been working professionally with Laravel for a couple of years now, but I still feel like I have significant gaps in my understanding of best practices.

For example, one of the projects we're working on is a large web app hosted on Laravel Vapor, but it doesn’t have any migrations. The lead developer claims that we should never run migrations in production because it could override production data.

Is the lead developer correct? It seems to me that migrations are an effective way to version control for DB changes, so I don’t understand why we shouldn’t use them in production. As I mentioned earlier, I’m aware of my gaps in knowledge regarding best practices but I suspect there isn't an issue with running migrations on production as long as one doesn't run php artisan migrate:fresh, but what makes me hesitate is that Vapor by default prevents running php artisan migrate, and will require the use of --force to run migrations on production. So, if Laravel Vapor is worried about running migrations on production, maybe my lead manager is correct. What are your thoughts?

Thank you!

0 likes
5 replies
LaryAI's avatar
Level 58

Running migrations in a production environment is a common practice and is generally considered safe when done correctly. Migrations are indeed an effective way to manage and version control database schema changes. However, there are some best practices and precautions you should follow to ensure that running migrations in production does not lead to data loss or downtime:

  1. Understand the Risks: Running migrations can potentially lead to data loss if not handled carefully, especially if the migration involves dropping tables or columns. Always review your migration scripts to ensure they do not inadvertently delete or alter critical data.

  2. Back Up Your Database: Before running any migrations in production, ensure you have a recent backup of your database. This allows you to restore the database to its previous state in case something goes wrong.

  3. Use the --force Flag Cautiously: Laravel requires the --force flag to run migrations in production to prevent accidental execution. This is a safeguard to ensure that you are consciously making the decision to apply changes to your production database.

    php artisan migrate --force
    
  4. Test Migrations in a Staging Environment: Before applying migrations to production, test them in a staging environment that mirrors your production setup. This helps identify any potential issues that could arise during the migration process.

  5. Avoid Destructive Operations: Be cautious with operations that can lead to data loss, such as dropping tables or columns. If you need to remove a column, consider deprecating it first and removing it in a later migration after ensuring it is no longer in use.

  6. Plan for Downtime: Some migrations, especially those involving large datasets or complex operations, may require downtime. Plan your migrations during off-peak hours to minimize the impact on users.

  7. Communicate with Your Team: Ensure that your team is aware of the migration and any potential impacts. This includes coordinating with developers, operations, and any other stakeholders.

  8. Monitor the Migration Process: Keep an eye on the migration process and be prepared to intervene if something goes wrong. Having a rollback plan is crucial.

In summary, while your lead developer's concerns are valid, running migrations in production is a standard practice when done with the necessary precautions. Laravel Vapor's requirement for the --force flag is a reminder to be deliberate and careful when making changes to a production database.

1 like
jlrdw's avatar

Read Larys number 1 and 2 above. Backup prior to messing with migrations in production.

I advise don't do it. A while back a user lost over 7 months of real company data.

Hector-moya's avatar

Thanks, @jlrdw; what approach would you recommend is the best practice to modify the production DB?

jlrdw's avatar
jlrdw
Best Answer
Level 75

@Hector-moya Practice on a duplicate first.

But I would dump data, backup, modify, and reupload (import) as needed.

If doing live DB just be careful. If only a few hundred records you are fine, but to re-migrate with millions, I wouldn't. Just my opinion.

Please or to participate in this conversation.