In your organization, you may have multiple customer facing applications to capture transactions or order from your end users. You also may have back-office and analytical applications using which you run your business and make decisions. Depending on when they were provisioned, these databases may be utilizing runtime and storage infrastructure of varied types of maturity. You may be looking to migrate these to a cloud environment such as the AWS, Azure or Google Cloud. Furthermore, you may be looking to move them to a more open source database. In this document we will give you a high level strategy and approach. You may be implementing some of these steps already, please contact us for more details and supporting your efforts as needed.
The best migration strategy these days is to select an approach that take full advantage of the cloud platforms. This could include migrating your applications and databases to cloud-native databases depending on the purpose they are used for. There is no need to stick to the old-guard on-premise databases anymore.
To determine the best strategy for modernizing your database, it is important to understand both qualitative and qunatitative aspects of its usage. Qualitative attributes include topics such as workload nature, transactional and analytical aspects, type of data (relational/structured or un-structured) and quantiative attributes include topics such as volume of data, growth potential, and availability requirements. Depending on such factors you can determine your strategy and approach to modernize you database and select an appropriate target environment.
Assess and Prepare
During assessment and 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. Please contact us for additional details regarding the tools. These tasks/questions are discussed below:
The following questions must be asked and answered. There are some tools such as Azure Migrate Service and AWS Database Migration Service, Schema Conversion Tools
etc that can used to answer some of the qualitative and quantitative aspects for below questions.
- What other applications and data sources that this database is dependent on (database links, integration services, ETLs etc.)
- What other applications and data sources are dependent on this database (database links, integration services, ETLs etc.)
- What are the hardware dependencies.
- What are the bandwidth and networking dependencies.
- Are there special database engine features that the legacy database software has.
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 an instance of database on the cloud or to another cloud-native database engine such as AWS DynamoDB, Azure Cosmos DB or AWS Aurora PostgreSQL. You can use AWS workload qualification framework or Azure Database Migration Assistant to help identify the complexity of your migration of oracle, sql server etc. to another database on the cloud. There are other tools that can give you a lot of detailed information. For example if you wish to migrate your Oracle database to PostgreSQL Ora2Pg provides detailed workload reports with potential areas to work on. We have extensive experience with such tools and can suggest a best possible approach to conduct your migration.
In this phase, you use the information gathered during the assessment and preparation phase and come up with the migration strategy. A critical aspect of migration planning is rationalizing the information you collected against the 6 Rs of migration: rehost, replatform, refactor/re-architect, repurchase, retire, and retain. Choosing your migration strategy depends on your business drivers for cloud adoption, as well as time considerations, business and financial constraints, and resource requirements. If you want to sustain your current workload in the cloud, choose rehosting. However, if you want to optimize and scale your workloads, consider one of the other options. Please see below a decision matrix that we recommend our clients.
After you complete migration planning and identify a migration strategy, the actual migration takes place. In this phase, the target database is designed, the source data is migrated to the target, and the data is validated.
This is an iterative process that includes multiple cycles of conversion, migration, and testing. After the functional and performance testing is complete, you can cut over to the new database. The migration phase consists of the following key steps, which are discussed in the following sections:
- Converting the schema
- Migrating the data
- Updating the application
- Testing the migration
- Cutting over to the new database
Operation and Optimize
When your database is in Azure or AWS compute services, you have to operate it in the cloud. You need to make sure that you are following the best practices for areas such as monitoring, alerting, backups, and high availability. The operation overhead of rehosted databases is higher than the databases that have been re-platformed or refactored to use a managed cloud database service:
- A rehosted database runs on an Azure or AWS compute instance or a database service. You’re responsible for all database management tasks such as setting up backups, high availability, and disaster recovery solutions.
- If you re-platform or refactor your database on Amazon RDS, these database management tasks require only a few clicks to set up. This means that the database administrator will spend less time managing a database in Amazon RDS, compared with managing a rehosted database on an EC2 instance. Amazon RDS also provides a performance monitoring tool called Amazon RDS Performance Insights, which enables even non-experts to detect performance problems by using an easy-to understand dashboard that visualizes database load.
No matter which migration option you choose, we are available to assist and successfully complete your project. Please contact us at firstname.lastname@example.org for additional information.