Choose a migration strategy
In the majority of the database migrations, you can choose to rehost, replatform, or refactor. Any of these strategies can work for you. The guiding principle should be how you can get the maximum benefit out of your migration. Choosing to refactor your application and migrate to a cloud-native database such as Aurora can enable you to enhance your database application. However, depending on your workload complexity, refactoring a database can be time-consuming and resource-intensive.
The WQF categorization helps you decide when you should consider a particular migration strategy. A higher WQF category means that the migration effort required is significant; therefore, you might want to choose another option, such as rehost or replatform, to complete the migration within an acceptable timeframe. The following table shows the suggested strategies based on the WQF category.
| Category | Workload complexity | Workload | Migration strategy |
|---|---|---|---|
| 1 |
|
ODBC/JBDC workloads | Candidate for refactor |
| 2 |
|
Light, proprietary feature workloads | Candidate for refactor |
| 3 |
|
Heavy, proprietary feature workloads | Candidate for refactor or replatform |
| 4 |
|
Engine-specific workloads | Candidate for replatform or rehost |
| 5 |
|
Non-portable, high-risk, or lift-and-shift workloads | Candidate for replatform or rehost |
The rehost and replatform options are suitable when the complexity involved in refactoring is high. In these scenarios, based on your modernization needs, you might consider refactoring your database after you have completed the migration to the AWS Cloud.
