Estoy en la fase de investigación tratando de adoptar Proyectos de base de datos de 2012 en un proyecto pequeño existente. Soy un desarrollador de C #, no un DBA, por lo que no soy particularmente fluido con las mejores prácticas. He estado buscando en google y stackoverflow durante algunas horas pero todavía no sé cómo manejar algunos escenarios de implementación clave correctamente.

1) En el transcurso de varios ciclos de desarrollo, ¿cómo administro varias versiones de mi base de datos? Si tengo un cliente en v3 de mi base de datos y quiero actualizarlo a v8, ¿cómo administro esto? Actualmente administramos scripts de migración de datos y esquemas hechos a mano para cada versión de nuestro producto. ¿Todavía necesitamos hacer esto por separado o hay algo en el nuevo paradigma que lo respalda o reemplaza?

2) Si el esquema cambia de tal manera que requiere que los datos se muevan, ¿cuál es la mejor manera de manejar esto? Asumo que parte del trabajo se realiza en la secuencia de comandos de implementación previa para conservar los datos y luego la secuencia de comandos posterior a la implementación lo coloca de nuevo en el lugar correcto. ¿Es así o hay algo mejor?

3) ¡Cualquier otro consejo u orientación sobre cómo trabajar mejor con estas nuevas tecnologías también es muy apreciado!

ACTUALIZAR: Mi comprensión del problema ha aumentado un poco desde que formulé esta pregunta y, aunque se me ocurrió una solución viable, no era exactamente la solución que esperaba. Aquí está una nueva redacción de mi problema:

El problema que estoy teniendo es puramente relacionado con los datos. Si tengo un cliente en la versión 1 de mi aplicación y quiero actualizarlo a la versión 5 de mi aplicación, no tendría ningún problema si su base de datos no tuviera datos. Simplemente dejé que SSDT compare esquemas de forma inteligente y migre la base de datos de una sola vez. Desafortunadamente los clientes tienen datos, así que no es tan simple. Los cambios de esquema de la versión 1 de mi aplicación a la versión 2 a la versión 3 (etc.) afectan todos los datos. Mi estrategia actual para administrar datos requiere mantener un script para cada actualización de la versión (1 a 2, 2 a 3, etc.). Esto me impide pasar directamente de la versión 1 de mi aplicación a la versión 5 porque no tengo un script de migración de datos para ir directamente allí. La posibilidad de crear scripts de actualización personalizados para cada cliente o administrar scripts de actualización para pasar de cada versión a cada versión mayor es exponencialmente inmanejable. Lo que esperaba era que existiera algún tipo de estrategia que permita SSDT que facilite la gestión del lado de los datos de las cosas, tal vez incluso tan fácil como el lado del esquema de las cosas. Mi experiencia reciente con SSDT no me ha dado ninguna esperanza de que exista tal estrategia, pero me encantaría averiguarlo de manera diferente.