Migrations can process both a structure (scheme) and data, but once you roll, it is assumed that in most cases your production data is a canonical source of information. If there is data necessary for setting up the database, for example, such as lists ("Mastercard, Visa, Amex") or boot data (for example, setting up the administrator), it can be in the file "seed.rb". which makes a copy of the database (schema and content) and automatically applies it - this is usually a one-time thing.
(Moving in the other direction - copying a production database to QA or development instances is a common precedent. At first you might think: Rails should do this. But copying a typical production database may involve the most important ones: copying the production database with information about the user is a significant security risk; any copy operation should at least make users anonymous. The second problem is simply the size of the database: a production database is often useful or even necessary to reproduce real performance problems or other cases, but any large database will ultimately take a long time to replicate and will depend heavily on the specific database you are using and on permissions)
In short, Rails does the right thing with migration: assumes structural updates are fine, but you need to populate the data. Hope this helps!