Eu estou na fase de pesquisa tentando adotar 2012 Database Projects em um projeto pequeno existente. Eu sou um desenvolvedor de C #, não um DBA, então não sou particularmente fluente com as práticas recomendadas. Estou pesquisando o google e stackoverflow há algumas horas, mas ainda não sei como lidar corretamente com alguns dos principais cenários de implantação.

1) Ao longo de vários ciclos de desenvolvimento, como gerencio várias versões do meu banco de dados? Se eu tiver um cliente na v3 do meu banco de dados e quiser atualizá-lo para a v8, como gerencio isso? Atualmente gerenciamos esquemas manuais de migração de dados e esquemas para cada versão do nosso produto. Ainda precisamos fazer isso separadamente ou há algo no novo paradigma que apóie ou substitua isso?

2) Se o esquema mudar de tal forma que exija que os dados sejam movidos, qual é a melhor maneira de lidar com isso? Eu suponho que algum trabalho vai no script de pré-implantação para preservar os dados e, em seguida, o script Post-Deploy coloca de volta no lugar certo. É assim ou há algo melhor?

3) Qualquer outro conselho ou orientação sobre como melhor trabalhar com essas novas tecnologias também é muito apreciado!

ATUALIZAR: Minha compreensão do problema cresceu um pouco desde que eu originalmente fiz esta pergunta e, enquanto eu encontrei uma solução viável, não era bem a solução que eu esperava. Aqui está uma reformulação do meu problema:

O problema que estou tendo é puramente relacionado a dados. Se eu tiver um cliente na versão 1 do meu aplicativo e quiser atualizá-lo para a versão 5 do meu aplicativo, não teria problemas em fazer isso se o banco de dados deles não tivesse dados. Eu simplesmente deixaria o SSDT comparar de maneira inteligente os esquemas e migrar o banco de dados de uma só vez. Infelizmente os clientes têm dados, por isso não é tão simples. Mudanças de esquema da versão 1 do meu aplicativo para a versão 2 para a versão 3 (etc), todos os dados de impacto. Minha estratégia atual para gerenciar dados requer que eu mantenha um script para cada atualização de versão (1 a 2, 2 a 3, etc). Isso me impede de ir direto da versão 1 do meu aplicativo para a versão 5, porque não tenho script de migração de dados para ir direto para lá. A perspectiva de criar scripts de atualização personalizados para cada cliente ou gerenciar scripts de atualização para ir de todas as versões para todas as versões maiores é exponencialmente incontrolável. O que eu esperava era que houvesse algum tipo de estratégia que o SSDT possibilite que torne o gerenciamento do lado dos dados mais fácil, talvez até tão fácil quanto o lado do esquema das coisas. Minha recente experiência com o SSDT não me deu nenhuma esperança de que tal estratégia existisse, mas eu adoraria descobrir de forma diferente.