anjanesh's avatar

php artisan migrate attempted running from the first migration file instead of the last one(s)

When I ran php artisan migrate on my server why didn't it automatically run the last migration file ? Why did it try starting from the first one instead ? I checked the database - all but the last one were listed in the migrations table.

 INFO  Running migrations.  

  2014_10_12_000000_create_users_table ................................................................................................ 10.45ms FAIL

   Illuminate\Database\QueryException 

  SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'users' already exists (Connection: mysql, SQL: create table `users` (`id` bigint unsigned not null auto_increment primary key, `name` varchar(125) not null, `email` varchar(125) not null, `email_verified_at` timestamp null, `password` varchar(125) not null, `remember_token` varchar(100) null, `created_at` timestamp null, `updated_at` timestamp null) default character set utf8mb4 collate 'utf8mb4_unicode_ci')

  at vendor/laravel/framework/src/Illuminate/Database/Connection.php:824

I had to resort to running php artisan migrate --path=/database/migrations/2026_03_04_080009_change_schema_tag_column_length_in_products_table.php on PROD.

0 likes
5 replies
LaryAI's avatar
LaryAI
AI
1 month ago
Level 58

Certainly! Here’s an explanation of why this happened and the correct solution.

Why Did php artisan migrate Try All Migrations?

When you run php artisan migrate, Laravel checks the migrations table in your database to determine which migration files have already been run. It will attempt to run any migration that is not yet recorded in that table.

In your case, even though the database tables existed, Laravel's migrations table was missing an entry for the last migration file(s). That’s why running php artisan migrate tried to re-run earlier migrations like the one attempting to create the users table (which already existed), resulting in the error:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'users' already exists

This means not all migrations were recorded as "applied" in the migrations table.

How To Fix It (Recommended Approach)

  1. Check the migrations table in your database.
    It contains one row for each migration file that has been run.

  2. If a migration has been applied manually (i.e., its changes exist in the DB, but it’s not in the migrations table), Laravel assumes it is pending and tries to run it again.

  3. The Correct Solution:
    If the earlier migrations already ran and those DB schema changes exist, but the migration is not in the table, you need to add a row in the migrations table for each migration file that has (already) been applied.

    Manually Insert Missing Migrations:

    INSERT INTO migrations (migration, batch)
VALUES ('2014_10_12_000000_create_users_table', 1);

    Repeat for each migration that should be marked as "done".
    The batch number groups migrations; just increment it or use the highest seen in your table.

  4. After updating the table, running php artisan migrate will only execute migrations that haven’t been marked as complete, i.e., only the newest ones.

Best Practice

Never manually change the schema on production without updating the migrations table, or you can end up in this state. Always let Laravel migrate, so the migrations table stays in sync.
If you’re forced to run or skip migrations manually, you should always ensure the migrations table correctly reflects their status.

Summary

  • Why it happened: Laravel’s migrations table didn’t have all the entries for applied migrations.
  • How to fix: Add records for already-applied migrations to the migrations database table.
  • Best practice: Only ever run migrations using Laravel’s migration system.

Let me know if you need specific SQL for your missing migrations, or have more questions!

Glukinho's avatar

Check config/database.php - migrations key, did you change it? Default value is:

'migrations' => [
        'table' => 'migrations',
        'update_date_on_publish' => true,
],
anjanesh's avatar

Nothing was changed in config/database.php - using default values.

Glukinho's avatar

Well obviously Laravel doesn't see already run migrations. Did you check migrations table specifically in production database? Did you by chance check only local/dev database?

anjanesh's avatar

Checked it online - it was at cloudways.

Please or to participate in this conversation.