# Phase 1: Prepare


 The first phase of the database migration process is preparation. During preparation, you identify the interdependencies between your applications and databases. You also analyze the database workloads to determine the migration categories: from simple rehost (homogeneous) migration to re-architect (heterogeneous) migration. Without completing this phase, you risk running into delayed migration timelines.

These tasks are discussed in the following sections:
+ [Identifying dependencies](id-dependencies.md)
+ [Qualifying workloads](qualify-workloads.md)

# Identify dependencies


 You start by identifying application and database dependencies, by asking questions such as the following:
+ Is this database directly accessed by any other application?

  If so, you should determine how migrating the database affects that application. If you’re rehosting the database, you need to make sure that the application can still access the database with acceptable performance.
+ Does the application directly access any other database?

  If so, determine the migration plan for the other database. If it’s also migrating, you need to update the application accordingly. If it isn’t migrating, you need to make sure that the application can continue to connect to it with acceptable latency.
+ Is the database using database links to fetch data from other databases? 

  As in the previous point, determine the migration plan for the other database and handle the links accordingly.
+ Is the application dependent on any on-premises software? 

  If so, you should determine the migration plan for that software. If it’s migrating, you need to update your application accordingly. If it isn’t, make sure that the application can continue to connect to the software and the latency is acceptable.
+ Are there any hardware dependencies? 

  If so, come up with a plan to address those.
+ Are there any strict bandwidth or networking requirements? 

  If so, choose the AWS services that can help you meet these requirements.
+ Does the application use any special database engine options or features?

  If you’re migrating to a different database engine, you need to update the application accordingly.

If the answers to these questions are complex, a better option is to decouple the database from the application by using microservices. This way, an application can get data by calling the microservice instead of directly connecting to the database.

# Qualify workloads


 To determine the best migration strategy for your database, it’s important to understand the current database workload. You need to analyze your database to determine which features you are currently using and what’s involved in migrating to another cloud-native database engine such as [Amazon Aurora PostgreSQL](https://aws.amazon.com/rds/aurora/).

AWS provides a workload qualification tool called AWS Workload Qualification Framework (AWS WQF). This tool can help identify the complexity of your Oracle and Microsoft SQL Server database migration by analyzing database schemas and code objects, application code, dependencies, performance characteristics, and similar inputs. WQF provides recommendations on the target database engine. It also estimates the type of work involved and the level of effort required.

WQF evaluates your migration workload and places it in one of five workload categories, summarized in the following table.

 ![\[Five migration workload categories reported by WQF\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-database-migration/images/wqf-categories.png) 
+ **Category 1:** Workloads that use Open Database Connectivity (ODBC) or Java Database Connectivity (JDBC) instead of proprietary drivers to connect to the database. This category typically has simple stored procedures that are used for access controls. The conversion requires fewer than 50 manual changes.
+ **Category 2:** Workloads with light use of proprietary features and that don't use advanced SQL language features. This type of workload requires fewer than 200 manual changes.
+ **Category 3:** Workloads with heavy use of proprietary features. Workloads in this category are completely driven by advanced stored procedure logic or proprietary features. This type of workload requires more than 200 manual changes that involve database-resident code and features.
+ **Category 4:** Engine-specific workloads. Workloads in this category use frameworks that can work only with a specific commercial database engine. For example, these frameworks might include Oracle Forms, Oracle Reports, Oracle Application Development Framework (ADF), Oracle Application Express (APEX), or applications that use .NET ActiveRecord extensively.
+ **Category 5:** Nonportable, unacceptable risk, or "lift and shift" workloads. Workloads in this category might be implemented on database engines that have no cloud-based equivalent. In some cases, you might not have the source code for these programs.

This categorization can help you determine the migration path for your application, as we’ll discuss in the section [Phase 2: Plan](planning-phase.md).

AWS doesn’t currently provide AWS WQF for downloading. If you need help assessing a migration to AWS with AWS WQF, we recommend opening a support ticket. AWS will engage with you directly to help make the process work for you.