Oi Magno,

na realidade é absolutamente o contrário: o Migration é voltado para o ambiente de produção. Ele te trás algumas funcionalidades bastante interessantes nesta área inclusive como, por exemplo, a possibilidade você executar o rollback de algumas das suas operações caso uma ou mais condições (definidas por você) não sejam satisfeitas.

É uma alternativa bastante interessante: por coincidência, estou desenvolvendo um plug-in similar ao Migration de uso mais simples: quando precisamos apenas executar algumas operações em produção, e não a alteração completa do banco.

E como se dá o uso do plugin em produção já que, até onde percebi, ele é baseado em scripts para o console grails?

Bom:
o migration cria por padrão para você duas tabelas: "databasechangelog" e "databasechangeloglock". A primeira armazena as mudanças (changesets) que já foram executadas no banco de dados, enquanto a segunda consiste em um lock, útil para ambientes clusterizados, que evita a ocorrência de dois nós estarem executando os changesets ao mesmo tempo.
Neste caso, tudo o que você precisa fazer é ir atualizando o seu relatório de mudanças com os comandos diff dele (gormdiff) se não me engano para que, em produção, estas mudanças sejam executadas na sequência. Mas para isto é necessário que você inclua uma chave de configuração no seu arquivo Config.groovy. A chave se chama grails.plugin.databasemigration.updateOnStart e deve receber o valor true. Aí toda vez que o sistema for executado, será verificado se há mudanças no banco de dados e, havendo, as mesmas serão executadas caso já não tenham sido.
Uma das partes mais úteis da documentação é este link: http://grails-plugins.github.io/grails-database-migration/docs/manual/guide/configuration.html
Nele você vê todas as chaves de configuração do plug-in.

A explicação do Kico foi perfeita.

Em um sistema que fiz usando Grails (http://abasteca.me), usei o Database Migration para fazer o controle das alterações no banco de dados. Nas primeiras versões, eu tinha um "ritual" um tanto monótono cada vez que ia atualizar a versão. Primeiro, fazia um "update" no código-fonte (sim, eu tinha um workspace no servidor só pra fazer isso), parava o servidor de aplicação (Tomcat, no meu caso),  rodava, o comando "grails dbm-update" para que os scripts fossem executados e o banco atualizado, rodava o "grails war" pra gerar o artefato, substituía o arquivo no Tomcat e no fim tornava subí-lo. Depois de estudar sobre integração contínua e deploy automático usando o Codeship, resolvi automatizar o processo de atualização do banco setando a propriedade grails.plugin.databasemigration.updateOnStart como true no Config.groovy. Dessa forma, não preciso mais fazer todo esse processo. A própria aplicação é responsável pela atualização enquanto está subindo. Continuo gerando os scripts via linha de comando no ambiente de desenvolvimento (grails dbm-diff e grails dbm-gorm-diff), mas não me preocupo mais com isso no ambiente de produção.

Obrigado, Kiko e Wilian, este grails.plugin.databasemigration.updateOnStart parece ser o que eu estava procurando.