Migrations aren't only for schema changes.
Sometimes a migration also needs to reshape existing data, like backfilling a newly-created column or renaming a value across every row. I wrote more about doing that safely in a previous tip.
When you do touch data in a migration, you have a choice. You can go through the Eloquent model, or you can use the DB facade with a table name.
We're so used to Eloquent for data access, but for a plain data change inside a migration, my recommendation is to instead use the DB facade.
Why? Remember that a migration doesn't just run once. It runs every time you run your test suite or every time you spin up a fresh environment.
Models, on the other hand, may not live forever. You rename them, move them, or swap out the package that defines them. The moment that happens, a migration that referenced one of those models breaks retroactively, even though it ran fine the day you wrote it.
The table name is a far more stable contract, so binding the migration to the table keeps it working.
There's a second reason worth considering too. A migration lives at the database layer, not the domain layer. Even without a deletion or renaming, models can accumulate behavior over time that affects how migrations run. For example, casts, global scopes, or observers can all produce side effects you didn't intend.
This isn't an absolute rule, of course. There are still times when reaching for the model is the right call, and there's a trade-off worth weighing before you default to the DB facade. I'll dig into both in a follow-up tip, including a counter-example where we deliberately keep using a model and one important trade-off to consider when following this advice.
Here to help,
Joel
P.S. Want more bite-sized Laravel tips like this one? We collect them each quarter in a tips volume that's easy to search and revisit.
