

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Fase 1: preparación
<a name="preparation-phase"></a>

 La primera fase del proceso de migración de la base de datos es la preparación. Durante la preparación, usted identifica las interdependencias entre las aplicaciones y las bases de datos. También analiza las cargas de trabajo de las bases de datos para determinar las categorías de la migración: desde la simple migración para volver a alojar bases de datos (homogénea) hasta la migración con rediseño (heterogénea). Si no completa esta fase, corre el riesgo de sufrir retrasos en los tiempos de migración.

En las próximas secciones se ofrece información sobre estas tareas:
+ [Identificación de dependencias](id-dependencies.md)
+ [Calificación de las cargas de trabajo](qualify-workloads.md)

# Identificación de dependencias
<a name="id-dependencies"></a>

 Comience por identificar las dependencias entre aplicaciones y bases de datos, formulando preguntas como las siguientes:
+ ¿Alguna otra aplicación accede directamente a esta base de datos?

  Si es así, debe determinar cómo afecta la migración de la base de datos a esa aplicación. Si va a volver a alojar la base de datos, debe asegurarse de que la aplicación pueda seguir accediendo a la base de datos con un rendimiento aceptable.
+ ¿Esta aplicación accede directamente a alguna otra base de datos?

  Si es así, decida el plan de migración para la otra base de datos. Si esa otra base de datos también está migrando, entonces debe actualizar la aplicación en consecuencia. Si no está migrando, debe asegurarse de que la aplicación pueda seguir conectándose a ella con una latencia aceptable.
+ ¿La base de datos utiliza enlaces a bases de datos para obtener datos de otras bases de datos? 

  Como en el punto anterior, decida el plan de migración para la otra base de datos y administre los enlaces en consecuencia.
+ ¿La aplicación depende de algún software en las instalaciones? 

  Si es así, debe determinar el plan de migración de ese software. Si ese software también está migrando, entonces debe actualizar la aplicación. Si no está migrando, debe asegurarse de que la aplicación pueda seguir conectándose al software con una latencia aceptable.
+ ¿Existen dependencias de hardware? 

  Si es así, elabore un plan para abordarlas.
+ ¿Existen requisitos estrictos de ancho de banda o de red? 

  Si es así, elija los servicios de AWS que puedan ayudarlo a cumplir estos requisitos.
+ ¿Utiliza la aplicación alguna opción o característica especiales del motor de base de datos?

  Si va a migrar a un motor de base de datos diferente, debe actualizar la aplicación.

Si las respuestas a estas preguntas son complejas, una mejor opción es desacoplar la base de datos de la aplicación mediante microservicios. De esta forma, una aplicación puede obtener datos llamando al microservicio en lugar de conectarse directamente a la base de datos.

# Calificación de las cargas de trabajo
<a name="qualify-workloads"></a>

 Para determinar la mejor estrategia de migración para la base de datos, es importante comprender la carga de trabajo actual de la base de datos. Debe analizar su base de datos para determinar qué características utiliza actualmente y qué implica la migración a otro motor de base de datos nativo en la nube, como [Amazon Aurora PostgreSQL](https://aws.amazon.com/rds/aurora/).

AWS proporciona una herramienta de calificación de la carga de trabajo denominada AWS Workload Qualification Framework (o bien, AWS WQF). Esta herramienta puede ayudar a identificar la complejidad de la migración de bases de datos de Oracle y Microsoft SQL Server mediante el análisis de los esquemas de bases de datos y los objetos de código, el código de la aplicación, las dependencias, las características de rendimiento y entradas similares. WQF proporciona recomendaciones sobre el motor de base de datos de destino. También calcula el tipo de trabajo que supone y el nivel de esfuerzo requerido.

WQF evalúa la carga de trabajo de migración y la clasifica en una de las cinco categorías de carga de trabajo que se resumen en la tabla a continuación.

 ![\[Five migration workload categories reported by WQF\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/strategy-database-migration/images/wqf-categories.png) 
+ **Categoría 1:** cargas de trabajo que utilizan Open Database Connectivity (ODBC) o Java Database Connectivity (JDBC) en lugar de controladores de propietarios para conectarse a la base de datos. Esta categoría normalmente tiene procedimientos almacenados simples que se utilizan para los controles de acceso. La conversión requiere menos de 50 cambios manuales.
+ **Categoría 2:** cargas de trabajo que utilizan pocas características propias y que no utilizan características avanzadas del lenguaje SQL. Este tipo de carga de trabajo requiere menos de 200 cambios manuales.
+ **Categoría 3**: cargas de trabajo con uso intensivo de características propietarias. Las cargas de trabajo en esta categoría ser controlan totalmente mediante la lógica avanzada de procedimiento almacenada o características de propietarios. Este tipo de carga de trabajo requiere más de 200 cambios manuales que implican el código y las características residentes en la base de datos.
+ **Categoría 4**: cargas de trabajo específicas del motor. Las cargas de trabajo de esta categoría utilizan marcos de trabajo que solo pueden funcionar con un motor de base de datos comercial específico. Por ejemplo, estos marcos podrían incluir Oracle Forms, Oracle Reports, Oracle Application Development Framework (ADF) y Oracle Application Express (APEX) o aplicaciones que utilizan .NET ActiveRecord de forma generalizada.
+ **Categoría 5**: no portable, riesgo inaceptable o cargas de trabajo “migradas mediante lift-and-shift”. Las cargas de trabajo en esta categoría podrían implementarse en motores de base de datos que no tienen equivalente en la nube. En algunos casos, los clientes no tienen el código fuente para estos programas.

Esta categorización puede ayudarlo a determinar la ruta de migración de su aplicación, como veremos en la sección [Fase 2: planificación](planning-phase.md).

AWS actualmente no proporciona AWS WQF para su descarga. Si necesita ayuda para evaluar una migración a AWS con AWS WQF, le recomendamos que abra un ticket de soporte. AWSse pondrá en contacto directamente con usted para ayudarlo a que el proceso funcione.