Migrations are a huge step forward for many developers new to Rails – versioning the database is not all that common in, say, PHP. Over time, however, migrations can get unwieldy – as you accumulate more and more they can slow down, and early migrations can create conflicts with later code changes. We've been experimenting with one approach to deal with this with some success of late: consolidation. Basically, we develop with migrations normally, creating (for example) files numbered 001-010. Once the iteration is solid, we then push everything out to stage for testing, and assuming that passes we push it all to production. After the production release, we then consolidate the existing migrations into a single file that has the same number as the last migration file. In the example already mentioned, we'd create 010_consolidated_migration_for_[date].rb. All of the individual changes in the migrations get rolled up into the consolidated file, so that it represents a single step to initialize a new database. Subsequent iterations work much the same – new migrations are created in development on top of the consolidated migration (say, 011-015). Once they're tested and released, we consolidated again, merging 010-015 into a new 015 file. There's an obvious downside here – rolling back in production is made much more difficult after a consolidation. For our processes, that's not a huge problem, since we place a high priority on never rolling back the production DB. You could minimize the risk, however, by keeping a rolling window of consolidated migrations (so you'd have two or three consolidated files on production, each with the appropriate
self.down methods). Even then you wouldn't need to keep too many files, however, since you should rarely need to roll back more than one release.