The orthodox view is that migrations should reflect every previous
state of your database structure, so if an old version of your app is
deployed somewhere you can painlessly migrate it from there. Fiddling
with old migrations is also tricky because migrating back up can fail
(e.g. if you forgot to include something you did by hand,
But if the old migrations were just private (not deployed anywhere)
and some of them are nothing but confusing (dead ends, mistakes) I
sometimes gloss them over, because looking at migrations can be a good
way to learn what tables and fields are at the core of the app. Very
old migrations from a stage where the app wasn't functional yet can be
reduced to a schema.rb as Gregory said, and it's a good thing to do.
When I realize that I want to change something that logically belongs
in a very recent migration, I migrate up, edit the migration and
migrate back to the last version. That's relatively safe to do and
helps to keep an overview.