In this blog, you will learn how to migrate instances from HANA Services for BTP (on Cloud Foundry) to SAP HANA Cloud by using Self-Service Migration tool. You can find a detailed guide in Help Portal as well.
SAP HANA Cloud is a cloud-native database-as-a-service (DBaaS) for modern applications and analytics across all enterprise data. SAP HANA Cloud provides exciting new innovations and features that were not offered by SAP HANA Service on Cloud Foundry (CF) such as pay-per-usage billing, multi-tier storage, including a petabyte scale built-in data lake allowing you to scale computing and storage resources separately and elastically. SAP HANA Cloud also offers automated near-zero downtime upgrades, HA/DR (up to 99.99% SLA), and availability in a large variety of regions via four different cloud service providers, including Microsoft Azure, Google Cloud Platform (GCP), Amazon Web Services (AWS) and Alibaba Cloud. Last but not least, you can also achieve Total Cost Ownership (TCO) benefits, as it is cheaper to run comparable workloads on SAP HANA Cloud versus HANA Services on CF. You can always use Capacity Unit Estimator to anticipate the cost benefits you will have depending on your SAP HANA Cloud configuration. The guide document and blog post for this estimator tool are also provided.
SAP provides a Self-Service Migration Tool (hereinafter Self-Service tool) to help your migration journey to be easy and smooth. This tool:
Here is a high-level overview of the objects that can be migrated with the Self-Service migration tool.
The tool handles the migration of
1) HANA Service Database such as catalog, data, and secure store and
2) SAP HANA Schemas & HDI Containers Service Instances with HDI-Shared, Schema and Secure Store Plan.
The tool guides you through five phases: PLAN, PREPARE, EXECUTE, VALIDATE, and FINALIZE. You will learn each phase in a minute.
In regard to the Self-Service tool, there are several pre-requisites and disclaimers as below.
Now that you have acquainted yourself with these pre-requisites, let's move on to actual migration planning and execution. Each and every step will be presented with the screenshots, so that you can easily follow the process.
1) Go to SAP BTP cockpit and log in into your global account and sub account, and click Instances and Subscriptions in the navigation bar on the left.
2) You can find the detailed information of the sub account. If the provider is AWS, Azure, Alibaba Cloud or GCP, you are running on "Cloud Foundry". Otherwise, you are running in an SAP data center which uses the "Neo" platform as a service. This blog is about migration steps for Cloud Foundry case, and the tool supports all cloud service providers except for GCP.
3) When you click the Space that you want to migrate, you will see the source HANA Service database. You can also find HANA Schema & HDI Containers Service Instances with Schema, HDI and Secure Store plans which are bound to source HANA Service. Now, click SAP HANA Cloud in the left-side navigation bar.
4) Click Manage SAP HANA Cloud. There is another button (hidden behind the three dots) called Manage Migrations. You can click this button as well.
6) Fill in the Name of the migration project as you want, and choose the right Source Type. Your case would be SAP HANA Service (CF), provisioned after June 2018. You don't have to complete the project at one go - database migrations can be complex, and you can save your progress, and revisit different phases of the migration more than once.
7) Now, you are in the PLAN phase, where you get the source database ready. Here, you need a Cloud Foundry Technical User Credential. You can find more details about it in this page.
8) Select the source HANA Service that you want to migrate. Before running compatibility check, you need to create a Migration User in your source database with all required privileges to export data. Then, fill in the created credential information and click Check Compatibility with SAP HANA Cloud. The tool does a compatibility check and make any necessary preparations for migration.
9) You can see the compatibility check result. There are four levels of severity for the objects reported: Critical, Error, Warning and Info. Critical cases must be resolved, because you will not be able to proceed the migration without resolving them. You also need to review Error and Warning cases, and then you can either ignore or fix the reported objects at the source HANA service side depending on your review result. Error means these objects will not be migrated due to feature unavailability on HANA Cloud side, while Warning means these objects will be migrated but may have different behavior on HANA Cloud side. Lastly, Info means only informational.
For example, in the case above, for FullText Index error, you can maybe drop the Full Text Index columns from the source HANA database. And for Objects Owned By System error, you can move objects to another database user. Documentation in Feature Description column could show the resolution details. A list of affected objects are also shown in the last column. You can also check SQL statements in stored procedures and in the plan cache.
10) Now, you are in the PREPARATION phase. Let me underline once more about the migration user. It needs more privileges than the compatibility check, but if you've already followed the procedure described here, it's all good. The Self-Service tool can grant the privileges automatically at the beginning of the migration execution for the schemas that were created by instances of the service SAP HANA Schemas and HDI Containers. For all other schemas, privileges need to be granted manually.
Then you need to configure how the migration will be executed. Define a prefix (and a suffix) for the migrated service instance name and click Save and Proceed to Select Target.
11) Select Target Instance and enter database administrator user credential. Then you click Proceed to Execution Phase.
12) EXECUTION phase migrates the catalog, data, HDI containers, SAP HANA schemas & HDI containers service instances, and secure store from HANA Service to HANA Cloud. During execution, both databases must be online, but applications using the database must be offline. Execution is a single operation that should be completed within the downtime. Data transfer time depends on database size and structure, hence you could consider conducting test migrations, which will help to plan the required time.
The migration of each object will be executed in order from top to bottom.
When the migration is completed, you will see the following screen.
13) In VALIDATION phase, you will see a set of consistency checks on both metadata and data, including an optional record count check, to confirm that migration was successful. You can now start your own application-specific validation checks as well. Then, click Proceed to Finalization Phase.
14) You have three options (though the screenshot below shows two options) when you move to FINALIZATION phase: 1) You can choose None to finalize the migration process with no additional configuration, or 2) Delete the source service instances to delete the original service instances from the service managers and CF, or 3) Revert migration process changes to revert the service manager and CF to the state before migration. For example, suppose that you've discovered some problems that are preventing your applications to work properly with SAP HANA Cloud database during the business validation, the Revert option could let you delete the migrated CF instances of service SAP HANA Schemas and HDI Containers and restore Service Managers to the state before the migration. Thus, you can run again your applications on the source SAP HANA Service database until the problem is solved.
Here are some tips that you can refer to when you encounter any errors while using the Self-Service tool.
Hope that this blog helps you understand the migration process using the Self-Service Migration Tool, and thereby you can successfully migrate to SAP HANA Cloud. For further information regarding SAP HANA Cloud, please visit our product page.
- Benefits of migration to SAP HANA Cloud
- Pre-requisites and disclaimers to use the tool
- Part 1: Detecting and handling incompatibilities
- Part 2: Migrating database
- Additional tips and resources
1. Benefits of migration to SAP HANA Cloud
SAP HANA Cloud is a cloud-native database-as-a-service (DBaaS) for modern applications and analytics across all enterprise data. SAP HANA Cloud provides exciting new innovations and features that were not offered by SAP HANA Service on Cloud Foundry (CF) such as pay-per-usage billing, multi-tier storage, including a petabyte scale built-in data lake allowing you to scale computing and storage resources separately and elastically. SAP HANA Cloud also offers automated near-zero downtime upgrades, HA/DR (up to 99.99% SLA), and availability in a large variety of regions via four different cloud service providers, including Microsoft Azure, Google Cloud Platform (GCP), Amazon Web Services (AWS) and Alibaba Cloud. Last but not least, you can also achieve Total Cost Ownership (TCO) benefits, as it is cheaper to run comparable workloads on SAP HANA Cloud versus HANA Services on CF. You can always use Capacity Unit Estimator to anticipate the cost benefits you will have depending on your SAP HANA Cloud configuration. The guide document and blog post for this estimator tool are also provided.
SAP provides a Self-Service Migration Tool (hereinafter Self-Service tool) to help your migration journey to be easy and smooth. This tool:
- automates key migration tasks to reduce the cost and effort of migration,
- reduces uncertainties and helps to plan/prepare for migration by identifying potential issues upfront,
- is provided free of charge in SAP Business Technology Platform (BTP),
- doesn't require additional storage for migration and SAP manages the secure temporary storage for export and import.
Here is a high-level overview of the objects that can be migrated with the Self-Service migration tool.
The tool handles the migration of
1) HANA Service Database such as catalog, data, and secure store and
2) SAP HANA Schemas & HDI Containers Service Instances with HDI-Shared, Schema and Secure Store Plan.
The tool guides you through five phases: PLAN, PREPARE, EXECUTE, VALIDATE, and FINALIZE. You will learn each phase in a minute.
2. Pre-requisites and disclaimers to use the tool
In regard to the Self-Service tool, there are several pre-requisites and disclaimers as below.
- The tool only supports the migration of an SAP HANA Service database instance that was provisioned in the CF environment in regions run by AWS.
- The migration is available only within the same cloud database provider. For example, if you have HANA Service on AWS, you can migrate to SAP HANA Cloud on AWS only.
- The SAP HANA Service instance must be running SAP HANA Database Revision 53 or greater.
- Self-Service migration is an offline migration, which means the downtime for migration needs to be planned. The preparation steps can be performed prior to actual data migration.
- Some parts of your database setup cannot be migrated by the tool and must be handled manually. (e.g., Application code, Client-side SQL statements)
- Cloud Foundry extension landscapes are not supported.
Now that you have acquainted yourself with these pre-requisites, let's move on to actual migration planning and execution. Each and every step will be presented with the screenshots, so that you can easily follow the process.
3. Part 1: Detecting and handling incompatibilities
1) Go to SAP BTP cockpit and log in into your global account and sub account, and click Instances and Subscriptions in the navigation bar on the left.
2) You can find the detailed information of the sub account. If the provider is AWS, Azure, Alibaba Cloud or GCP, you are running on "Cloud Foundry". Otherwise, you are running in an SAP data center which uses the "Neo" platform as a service. This blog is about migration steps for Cloud Foundry case, and the tool supports all cloud service providers except for GCP.
3) When you click the Space that you want to migrate, you will see the source HANA Service database. You can also find HANA Schema & HDI Containers Service Instances with Schema, HDI and Secure Store plans which are bound to source HANA Service. Now, click SAP HANA Cloud in the left-side navigation bar.
4) Click Manage SAP HANA Cloud. There is another button (hidden behind the three dots) called Manage Migrations. You can click this button as well.
6) Fill in the Name of the migration project as you want, and choose the right Source Type. Your case would be SAP HANA Service (CF), provisioned after June 2018. You don't have to complete the project at one go - database migrations can be complex, and you can save your progress, and revisit different phases of the migration more than once.
7) Now, you are in the PLAN phase, where you get the source database ready. Here, you need a Cloud Foundry Technical User Credential. You can find more details about it in this page.
8) Select the source HANA Service that you want to migrate. Before running compatibility check, you need to create a Migration User in your source database with all required privileges to export data. Then, fill in the created credential information and click Check Compatibility with SAP HANA Cloud. The tool does a compatibility check and make any necessary preparations for migration.
9) You can see the compatibility check result. There are four levels of severity for the objects reported: Critical, Error, Warning and Info. Critical cases must be resolved, because you will not be able to proceed the migration without resolving them. You also need to review Error and Warning cases, and then you can either ignore or fix the reported objects at the source HANA service side depending on your review result. Error means these objects will not be migrated due to feature unavailability on HANA Cloud side, while Warning means these objects will be migrated but may have different behavior on HANA Cloud side. Lastly, Info means only informational.
For example, in the case above, for FullText Index error, you can maybe drop the Full Text Index columns from the source HANA database. And for Objects Owned By System error, you can move objects to another database user. Documentation in Feature Description column could show the resolution details. A list of affected objects are also shown in the last column. You can also check SQL statements in stored procedures and in the plan cache.
4. Part 2: Migrating database
10) Now, you are in the PREPARATION phase. Let me underline once more about the migration user. It needs more privileges than the compatibility check, but if you've already followed the procedure described here, it's all good. The Self-Service tool can grant the privileges automatically at the beginning of the migration execution for the schemas that were created by instances of the service SAP HANA Schemas and HDI Containers. For all other schemas, privileges need to be granted manually.
Then you need to configure how the migration will be executed. Define a prefix (and a suffix) for the migrated service instance name and click Save and Proceed to Select Target.
11) Select Target Instance and enter database administrator user credential. Then you click Proceed to Execution Phase.
12) EXECUTION phase migrates the catalog, data, HDI containers, SAP HANA schemas & HDI containers service instances, and secure store from HANA Service to HANA Cloud. During execution, both databases must be online, but applications using the database must be offline. Execution is a single operation that should be completed within the downtime. Data transfer time depends on database size and structure, hence you could consider conducting test migrations, which will help to plan the required time.
The migration of each object will be executed in order from top to bottom.
When the migration is completed, you will see the following screen.
13) In VALIDATION phase, you will see a set of consistency checks on both metadata and data, including an optional record count check, to confirm that migration was successful. You can now start your own application-specific validation checks as well. Then, click Proceed to Finalization Phase.
14) You have three options (though the screenshot below shows two options) when you move to FINALIZATION phase: 1) You can choose None to finalize the migration process with no additional configuration, or 2) Delete the source service instances to delete the original service instances from the service managers and CF, or 3) Revert migration process changes to revert the service manager and CF to the state before migration. For example, suppose that you've discovered some problems that are preventing your applications to work properly with SAP HANA Cloud database during the business validation, the Revert option could let you delete the migrated CF instances of service SAP HANA Schemas and HDI Containers and restore Service Managers to the state before the migration. Thus, you can run again your applications on the source SAP HANA Service database until the problem is solved.
5. Additional tips and resources
Here are some tips that you can refer to when you encounter any errors while using the Self-Service tool.
- The Self-Service tool can let you restart the process. When the catalog import was not successful, you should delete your SAP HANA Cloud instance, provision a new instance, and try migrating again.
- If the migration continues to fail, please create an incident for the component HAN-CLS-MIG. Report the error message with Migration Process ID, HANA Service Instance ID, HANA Cloud Instance ID, Region, and Pre-Migration Report (if you have).
- You can always reach out to migrationhelpdesk@sap.com if you have any technical queries related to your migration while using the Self-Service tool.
Hope that this blog helps you understand the migration process using the Self-Service Migration Tool, and thereby you can successfully migrate to SAP HANA Cloud. For further information regarding SAP HANA Cloud, please visit our product page.
- SAP Managed Tags:
2 Comments
