Estrategias de migración de bases de datos de SQL Server

En un nivel alto, hay dos opciones para migrar una base de datos de ASQL Server en las instalaciones a la nube de AWS: permanecer en SQL Server (migración homogénea) o dejar SQL Server (migración heterogénea). En una migración homogénea, no se cambia el motor de la base de datos. Es decir, la base de datos de destino también es una base de datos de SQL Server. En una migración heterogénea, cambia sus bases de datos SQL Server a un motor de base de datos de código abierto, como MySQL, PostgreSQL o MariaDB, o a una base de datos nativa en la nube de AWS, como Amazon Aurora, Amazon DynamoDB o Amazon RedShift.

Existen tres estrategias comunes para migrar las bases de datos de SQL Server a AWS: volver a alojar, redefinir la plataforma y rediseñar (refactorizar). Estas son parte de las 7 R de las estrategias de migración de aplicaciones y se describen en la siguiente tabla.

Strategy (Estrategia)	Tipo	Cuándo elegir	Ejemplo
Volver a alojar	Homogéneo	Desea migrar su base de datos SQL Server tal cual, con o sin cambiar el sistema operativo, el software de la base de datos o la configuración.	De SQL Server a Amazon EC2 (Examine los patrones para volver a alojar)
Cambio de plataforma	Homogéneo	Desea reducir el tiempo que dedica a administrar instancias de bases de datos mediante una oferta de base de datos como servicio.	De SQL Server a Amazon RDS para SQL Server (Examine patrones para redefinir la plataforma)
Rediseñar (refactorizar)	Heterogéneo	Desea reestructurar, reescribir y rediseñar la arquitectura de la base de datos y la aplicación para aprovechar las características de las bases de datos de código abierto y nativas en la nube.	SQL Server a Amazon Aurora PostgreSQL, MySQL o MariaDB Explore los patrones de rearquitectura)

Si está intentando decidir entre volver a alojar o redefinir la plataforma de sus bases de datos de SQL Server, consulte Cómo elegir entre Amazon EC2 y Amazon RDS más adelante en esta guía para ver una comparación en paralelo de las características compatibles.

Elegir la estrategia de migración correcta

La elección de la estrategia correcta depende de los requisitos empresariales, las limitaciones de recursos, el plazo de migración y las consideraciones de costos. El siguiente diagrama muestra el esfuerzo y la complejidad que implican las migraciones, incluidas siete de las estrategias.

La refactorización de la base de datos de SQL Server y la migración a una base de datos de código abierto o nativa en la nube de AWS, como Amazon Aurora PostgreSQL Edition o Amazon Aurora MySQL, puede ayudarlo a modernizar y optimizar su base de datos. Al migrar a una base de datos de código abierto, puede evitar licencias costosas (lo que se traduce en costos más bajos), períodos de dependencia de los proveedores y auditorías. Sin embargo, en función de la complejidad de la carga de trabajo, la refactorización de la base de datos de SQL Server puede ser una tarea complicada, lenta y que requiere muchos recursos.

Para reducir la complejidad, en lugar de migrar la base de datos en un solo paso, podría considerar un enfoque gradual. En la primera fase, puede centrarse en la funcionalidad básica de la base de datos. En la siguiente fase, podrá integrar servicios de AWS adicionales en su entorno de nube para reducir los costos y optimizar el rendimiento, la productividad y la conformidad. Por ejemplo, si su objetivo es sustituir la base de datos SQL Server en las instalaciones por otra compatible con Aurora MySQL-Compatible, podría considerar la posibilidad de volver a alojar la base de datos en Amazon EC2 o redefinir la plataforma de la base de datos en Amazon RDS para SQL Server en la primera fase y, a continuación, refactorizarla para que sea compatible con Aurora MySQL en una fase posterior. Este enfoque ayuda a reducir los gastos, los recursos y los riesgos durante la fase de migración y se centra en la optimización y la modernización en la segunda fase.

Migración online y offline

Puede usar dos métodos para migrar la base de datos SQL Server de un entorno en las instalaciones a la nube de AWS, en función de su cronograma de migración y del tiempo de inactividad que pueda permitir: migración en línea o migración fuera de línea.

• Migración sin conexión: este método se utiliza cuando la aplicación puede permitirse un tiempo de inactividad planificado. En la migración sin conexión, la base de datos de origen permanece sin conexión durante el período de migración. Mientras la base de datos de origen esté fuera de línea, se migrará a la base de datos de destino en AWS. Una vez finalizada la migración, se realizan comprobaciones de validación y verificación para garantizar la coherencia de datos con la base de datos de origen. Cuando la base de datos pasa todas las comprobaciones de validación, se realiza una transición a AWS conectando la aplicación a la base de datos de destino en AWS.

• Migración online: este método se utiliza cuando la aplicación requiere un tiempo de inactividad prácticamente nulo o mínimo. En la migración en línea, la base de datos de origen se migra a AWS en varios pasos. En los pasos iniciales, los datos de la base de datos de origen se copian en la base de datos de destino mientras la base de datos de origen sigue ejecutándose. En los pasos siguientes, todos los cambios de la base de datos de origen se propagan a la base de datos de destino. Cuando las bases de datos de origen y destino están sincronizadas, están listas para la transición. Durante la transición, la aplicación cambia sus conexiones a la base de datos de destino en AWS y no deja ninguna conexión a la base de datos de origen. Puede usar AWS Database Migration Service (AWS DMS) o las herramientas disponibles de AWS Marketplace (como Attunity) para sincronizar las bases de datos de origen y de destino.