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.