Basics of Oracle Cloud Migrations
This section provides you information about understanding and knowing the basics of migrating with Oracle Cloud Migrations.
Understanding Test Migration and Production Migration
The Oracle Cloud Migrations service functionality doesn't distinguish between VM migrations for testing and production purposes. However, the migration planning and execution functionality treat VM migrations for testing and production purposes differently. Therefore, we recommend that you plan a test migration first and then perform the production migration.
For such a migration functionality, we recommend that you create two separate migration plans within the same migration project; one for the test migration and another for the production migration.
Requirements for the Test Migration Planning
Ensure that you meet the following requirements when you create a test migration plan:
- Make VMs and applications operational: The goal of the test migration is to ensure that the VMs and the applications or services that you migrate are fully operational after they are migrated to OCI. If you identify that more changes are required to make them operational, either automate such changes or note them. This action helps you to quickly and reliably reproduce them during production migration.
- Build required network connectivity: Ensure that you build the required network connectivity for your migrated instances in the destination environment. To make the required changes in the networking configuration, change the terraform stacks generated within the migration plans.
- Verify entire application that uses multiple VMs: If you're migrating services or applications that use multiple VMs, verify the entire application during the test migration. This means you should check the migration and launch of the entire application using multiple VMs and not only the individual components running on separate VMs.
- Verify inconsistencies by shutting down the source:
Note that you can perform a test migration by using snapshots of the source
VMs while these VMs still keep running in the original deployment.
Also, note that the snapshot of different VMs is not taken at the same time. Therefore, there might be inconsistencies for complex applications that require the data on various servers to remain in synchronization. In such a scenario, perform a test migration where the source is shut down, similar to the production migration. However, this option requires some downtime of the source environment. Therefore, make sure that you plan the test migration properly.
- Plan the scope of testing required for production migration: Ensure to plan the scope of testing for the production migration in advance. You can complete the planned test successfully during the available maintenance time slot.
- Complete additional configuration changes: Make sure all additional configuration that needs to be performed for the migration are complete. These can be firewall changes, DNS updates, client configurations, and so on.
- Keep a roll-back plan handy: If the test migration does not go as planned, ensure that there exists a list of steps available to roll back partially or fully changed configuration. You can decide to roll back the configurations partially or fully depending on whether the migration attempt was unsuccessful. You should quickly restore the original functions.
You can perform the test migration as soon as one replication for each asset is complete. Typically, the first replication requires full data transfer. Therefore, the first replication is the longest.
Requirements for the Production Migration Planning
Ensure that you meet the following requirements when you create a production migration plan:
- Mitigate service outage: To mitigate a service outage during migration, plan a maintenance window for the outage.
- Ensure that no transaction is lost: To ensure that no
transaction is lost during the migration, shut down your source assets and
perform an additional replication. So, the most recent state is transferred
to the target assets.
Ensure to factor the time required for performing an additional replication into your migration maintenance window.
- Tag source assets for easy identification: Make sure that you have an easy way to identify your source assets in the management console (by tagging or a similar method) where you manage them. So, you can quickly and reliably identify these assets that need to be turned off before the last replication session.
- Rely on automation: Note that you have a limited time to complete the migration during the maintenance window interval. Be sure to leverage the automation scripts and maintain records during the test migrations. Later, you can put your action plan for a specific time and track your progress against the maintenance window interval.
- Have an action plan ready: Although there isn't any
assurance of the success of the production migration attempt, prepare to
decide based on the production migration attempt. After that, have an action
plan for both the success and failure scenarios.
If the migration attempt fails, roll back the configuration and relaunch the source assets. Note what didn't proceed as expected, and then plan to address the migration attempt in the next attempt.
If the production migration is successful and the services are now operating in OCI, mark your migration projects as complete so that the data replications stop. Typically, you might want to keep the source data available for a while, so that you can relaunch the source assets when any migration error happens. However, remember that Oracle Cloud Migrations doesn't support reverse replication. Therefore, a reverse migration might be more complex, and you should perform manual data transfer for application backup or restore. In such a case, consider fixing problems in the destination environment initially, because that might require the least effort.
Restoring Source Environment After Migration
After the migration is complete, you must clean the source environment, and power down all the migrated assets to ensure that the migration is complete and you can now operate on the new OCI environment. If you fail to clean up the source environment, there can be some clients who remain connected to the old resources and perform operations on outdated data.
To clean up the source environment, perform the following steps:
- Shut down all the migrated VMs that are migrated to OCI.
- Clean all snapshots on the VMware vCenter according to the policies of your organization.
- Remove all the migrated VMs from VMware vCenter and clean the vCenter server.
- Decommission all unnecessary network routes, as required.