Migrar Dbs MSSQL 2005, 2008, 2012 hacia 2019

No has probado llevandote el mismo respaldo y levantarlo en 2019 con el mismo managment studio?
si no tienen nada raro debiese ser simple.

Ufff difícil. Una duda, que objetivo tiene la migración??? La idea es cambiar el motor y mantener la compatibilidad de las bases??? O la idea es subir también la compatibilidad para ganar en features??. Hace tiempo hice una migración a azure sobre eso. Y depende del objetivo que tengas son las cosas que debes hacer

Battle-Cat dijo:

Estimados,

Acudo a su infinita sapiencia y experiencia para consultar lo siguiente.

Tengo bases de datos corriendo en motores viejos, SQL 2005, 2008, y 2012. Necesito migrar todas las DB a un nuevo server Sql 2019 (siempre microsoft).

Conocen o recomeindan alguna herramienta que nos ayude a asegurar la integridad del traspaso?

Gracias de antemano.

Haz clic para expandir...

Me imagino que la pregunta apunta a que no se te vayan a perder datos.

Así a lo bruto te diría que te asegures de que las aplicaciones que escriben en esas bases de datos estén detenidas, le tomas un respaldo a las bases viejas y lo cargas en la instalación nueva. Si confías en que ninguna aplicación escribió en la base de datos después de iniciado el respaldo, tu recuperación en la instalación nueva debería ser completa y sin pérdida de datos de negocio.

Si hay aplicaciones corriendo en todo momento supongo que podrían utilizar alguna herramienta de sincronización de base de datos pasiva para contingencia.

Gratuita Dudo que encuentres algo así.

Pagada Supongo que esto te puede servir, es barata.

Otra cosa, creo que no puedes migrar directo. Yo tenía una base en 2005 que tuve que pasar a 2012 y luego a 2019. Lo otro es que Microsoft posee una herramienta para lograr dónde te indica todos los warnings

Ojo @Zuljin , no es tan simple. Un motor 2005 puede tener objetos que tengan sentencias despreciadas, por lo tanto, cuando la aplicación que se conecta a la base llame al sp por ejemplo, te mandará el manso error. No es tan fácil de backup y restore. Lo otro es saber si mantiene compatibilidad, por ejemplo, restauro en 2019 pero la base mantiene compatibilidad con 2012. Funciona, pero pierde los features exclusivos de 2019. Por eso, es importante saber que es lo que se busca con la migración

fercas dijo:

Ojo @Zuljin , no es tan simple. Un motor 2005 puede tener objetos que tengan sentencias despreciadas, por lo tanto, cuando la aplicación que se conecta a la base llame al sp por ejemplo, te mandará el manso error. No es tan fácil de backup y restore. Lo otro es saber si mantiene compatibilidad, por ejemplo, restauro en 2019 pero la base mantiene compatibilidad con 2012. Funciona, pero pierde los features exclusivos de 2019. Por eso, es importante saber que es lo que se busca con la migración

Haz clic para expandir...

Esto es un dolor de cabeza, pero creo que si usa características de 2019, no tendria las DBs en tantos motores viejos.
Para salvar los datos es tan simple como pasar de 2005 a 2008 y luego 2019, resulta con cualquiera desde 2008 hacia arriba a 2019.
Si usa otras cosas, habria que revisar una por una....

la herramienta propietaria de microsoft que yo usé para la migración, con buenos resultados fue MAP(

Microsoft Assessment and Planning Toolkit). Ojo, que esta app te dice lo que no va a funcionar, no hace nada mas.​

GORDIO dijo:

Esto es un dolor de cabeza, pero creo que si usa características de 2019, no tendria las DBs en tantos motores viejos.
Para salvar los datos es tan simple como pasar de 2005 a 2008 y luego 2019, resulta con cualquiera desde 2008 hacia arriba a 2019.
Si usa otras cosas, habria que revisar una por una....

Haz clic para expandir...

claro, el problema es 2005. ahí tienes que pasar a un motor intermedio entre 2008 y 2012.

Una vez me encontré con sps donde los left joins los tenian con *=, sentencias super depreciadas, donde antes de migrar, había que modificar los sps.

Lo otro, que no se habló acá son los usuarios. estos se crean en el motor y luego se dan permisos en las bases. Si restauras la base, no te llevas los usuarios. Ojo ahí

claro, si tiene SPs, DTS o hasta scripts se pone más complejo. Por eso, IMHO, es malo meter logica de negocio a nivel de BD.
Pero si se usa solo para guardar datos, que seria lo ideal, a lo más pasar por un motor intermedio como mencionan.

Las herramientas de MS son buenas, recuerdo haber usado SSMA para llevar varias bases a motores SQLSERVER.

Kitsune dijo:

claro, si tiene SPs, DTS o hasta scripts se pone más complejo. Por eso, IMHO, es malo meter logica de negocio a nivel de BD.
Pero si se usa solo para guardar datos, que seria lo ideal, a lo más pasar por un motor intermedio como mencionan.

Las herramientas de MS son buenas, recuerdo haber usado SSMA para llevar varias bases a motores SQLSERVER.

Haz clic para expandir...

Efectivamente, en la mayoria de los casos no es la mejor idea meter la logica en la base, y actualmente los frameworks de desarrollo evitan eso, pero estamos hablando de bases 2008 y 2005, antiguas, donde se desarrollaba generalmente en 3 capas y habia mucho código en la base (a puro sp )

gracias a todos por la info. La idea es pasar info y ganar funcionalidades.. Las Db actualmente no tienen SP ni nada fancy, todo esta desarrollado por fuera.. Mañana comienzo con las migraciones, ahi les cuento como nos va..

Nuevamente gracias

Battle-Cat dijo:

gracias a todos por la info. La idea es pasar info y ganar funcionalidades.. Las Db actualmente no tienen SP ni nada fancy, todo esta desarrollado por fuera.. Mañana comienzo con las migraciones, ahi les cuento como nos va..

Nuevamente gracias

Haz clic para expandir...

Fuerza !!
Cualquier cosa rara, posteala aca...
A ver si podemos ayudar

acá pasamos de a a poco

lo otro puedes migrar directo de 2008 a 2019 con ssis pero cosas simples a nivel de datos , no es para la estructura

primera tarde noche, todo normal.. utilize finalmente el viejo conocido detach/attach.. movi aprox, 13 dbs.. sin novedades.. hoy seguiremos..