When developing on a long-term application, the data itself becomes an entity you must maintain and look after. You're consantly making releases and if you're "agile", priorities and features often change.
Before I had a simplistic approach to seeds vs migrations. Migrations simply being the architectural change of the database itself, while the seeds place data in the database itself.
Now the edgecase for this I've found is when introducing new features where you need to migrate or process data directly after running a schema migration. Often I would do this in one fell swoop within a single migration script.
There's no wrong way. These tools are for you and your team to decide on how to use them.
Lately after dealing with more and more data, as well as a recent episode on the Laravel Podcast, I've had a slighly different mindset and approach.
Migrations, for me and my team, are for three main tasks:
Seeders are now only ran for testing and faking purposes. This prevents the scenario of forgeting to run a seeder after a deployment. It also keeps the data layer always moving forward. No need to truncate or touch existing data.
While coming to this new mindset I also took a look at Laravel's actual Seed documentation. In the first sentence the word "test" is referenced.
This to me was a moment where I realized that there is valuable content in documentation besides examples. Though I may be biased, because Taylor Otwell spends hours on his documentation.
Snippet from Laravel documentation
"Laravel includes a simple method of seeding your database with test data using seed classes. All seed classes are stored in the database/seeds directory"