Laravel migrations: add a column, roll back, delete

Migrations version your database schema the way Git versions your code: every change is a file, replayable on any environment. Three operations cover most of the day-to-day work: adding a column to a table that already exists, rolling back a migration, and deleting a file that should never have been created.

Part of the Web development reading path. Every command and every output below was run on Laravel 13.30.1 with PHP 8.4.25.

Creating a migration

The command follows a naming convention that decides what ends up in the generated file:

php artisan make:migration create_tasks_table

The name starts with create, followed by the plural table name, followed by table. Laravel recognises this pattern and pre-fills Schema::create() with id() and timestamps(), the title column is added here for the example, and the generated comments have been removed:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        Schema::create('tasks', function (Blueprint $table) {
            $table->id();
            $table->string('title');
            $table->timestamps();
        });
    }

    public function down(): void
    {
        Schema::dropIfExists('tasks');
    }
};

If the table needs creation and update dates, $table->timestamps() adds them: leaving them out is what causes the “Unknown column ‘updated_at’” error.

Running the migration creates the table:

php artisan migrate

Adding a column to an existing table

Once the schema is in place, the everyday Eloquent queries do the rest. Never edit a migration that has already run: your colleagues and your servers have played it, and they will not play it again. Create a new migration instead, naming the table with --table:

php artisan make:migration add_notes_to_tasks_table --table=tasks

The generated file holds an empty Schema::table() in both directions. Fill them in: the column in up(), dropping it in down().

public function up(): void
{
    Schema::table('tasks', function (Blueprint $table) {
        $table->text('notes')->nullable()->after('title');
    });
}

public function down(): void
{
    Schema::table('tasks', function (Blueprint $table) {
        $table->dropColumn('notes');
    });
}

php artisan migrate

  2026_09_02_194036_add_notes_to_tasks_table .................... 47.43ms DONE

Two precautions are worth repeating here.

Make the column nullable, or give it a default value. On a table that already holds rows, a NOT NULL column with no default makes the migration fail: the database has nothing to put in the existing rows.

Always write the down(). That is what makes the migration reversible. A migration with no down() turns the smallest step backwards into a manual job.

Rolling back a migration that has already run

Start by looking at where you stand. migrate:status lists every migration with its batch and its state:

php artisan migrate:status

  2026_09_02_100000_create_tasks_table ............................... [1] Ran
  2026_09_02_194036_add_notes_to_tasks_table ......................... Pending

A Pending migration has never been played: its file can be deleted straight away. A Ran migration has to be rolled back first.

# rolls back the last migration only
php artisan migrate:rollback --step=1

# rolls back the whole last batch
php artisan migrate:rollback

The rollback runs the down() method. In the example above, the notes column does disappear from the table and the migration goes back to Pending. That is the moment, and not before, when you can delete the file.

Two neighbouring commands exist, to be kept for development:

# rolls back everything, then replays everything
php artisan migrate:refresh

# drops every table, then replays everything
php artisan migrate:fresh

Deleting a migration

There is no make:migration --delete: you delete a migration by deleting its file, in database/migrations, the folder returned by database_path() among the application paths. The only question is whether it has already run.

It has never run (Pending state): delete the file, nothing else.

rm database/migrations/2026_09_02_194036_add_notes_to_tasks_table.php

It has already run (Ran state): roll it back first, then delete the file.

php artisan migrate:rollback --step=1
rm database/migrations/2026_09_02_194036_add_notes_to_tasks_table.php

Changing an existing column

To change a type, a length or nullability, redeclare the column and add change():

public function up(): void
{
    Schema::table('tasks', function (Blueprint $table) {
        $table->string('title', 500)->change();
    });
}

Good news for anyone coming back from an old version: the doctrine/dbal package, required for this operation for years, has not been needed since Laravel 11. Checked on Laravel 13.30.1, where change() works with no extra dependency.