# Migrating SAP HANA to AWS: Patterns for AWS Migrations *Last updated: May, 2024* This guide describes the most common scenarios, use cases, and options for migrating SAP HANA systems from on-premises or other cloud platforms to the Amazon Web Services Cloud. This guide is intended for SAP architects, SAP engineers, IT architects, and IT administrators who want to learn about the methodologies for migrating SAP HANA systems to AWS, or who want to have a better understanding of migration approaches to AWS in general. This guide does not replace AWS and SAP documentation and is not intended to be a step-by-step, detailed migration guide. Some of the migration scenarios may involve additional technology, expertise, and process changes, as discussed in [later in this guide](migrating-hana-anydb-to-hana.md). **Note** To access the SAP notes and Knowledge Base articles (KBA) referenced in this guide, you must have an SAP ONE Support Launchpad user account. For more information, see the [SAP Support website](https://support.sap.com/en/my-support/knowledge-base.html). ## About this Guide This guide is part of a content series that provides detailed information about hosting, configuring, and using SAP technologies in the AWS Cloud. For the other guides in the series, ranging from overviews to advanced topics, see [SAP on AWS documentation](https://aws.amazon.com/sap/docs/). # Migration Frameworks Although this guide focuses on SAP HANA migrations to AWS, it is important to understand AWS migrations in a broader context. To help our customers conceptualize and understand AWS migrations in general, we have developed two major guidelines: 6 Rs and CAF. ## 6 Rs Framework The [6 Rs migration strategy](https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/) helps you understand and prioritize portfolio and application discovery, planning, change management, and the technical processes involved in migrating your applications to AWS. The 6 Rs represent six strategies listed in the following table that help you plan for your application migrations. | "R" migration strategy | Methodology | | --- | --- | | **Rehosting** | The application is migrated as is to AWS. This is also called a "lift-and-shift" approach. | | **Replatforming** | The application is changed or transformed in some aspect as part of its migration to AWS. | | **Repurchasing** | You move to a different application or solution on the cloud. | | **Refactoring / Re‑architecting** | The application is redesigned (for example, it’s converted from a monolithic architecture to microservices) as part of the migration to AWS. | | **Retiring** | The application is retired during migration to AWS. | | **Retaining** | The application isn’t migrated. | The decision tree diagram helps you visualize the end-to-end process, starting from application discovery and moving through each 6 R strategy. ![\[Image of a decision tree diagram to help you visualize the end-to-end process, starting from application discovery and moving through each 6 R strategy.\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-6rs.png) The two strategies that are specifically applicable for SAP HANA migrations to AWS are rehosting and replatforming. Rehosting is applicable when you want to move your SAP HANA system as is to AWS. This type of migration involves minimal change and can be seen as a natural fit for customers who are already running some sort of SAP HANA system. Replatforming is applicable when you want to migrate from an *anyDB* source database (such as IBM DB2, Oracle Database, or SQL Server) to an SAP HANA database. ## AWS CAF Framework The second guideline is the [AWS Cloud Adoption Framework (CAF)](https://aws.amazon.com/professional-services/CAF/). The AWS CAF breaks down the complex process of planning a move to the cloud into manageable pieces called *perspectives*. Perspectives represent essential areas of focus that span people, processes, and technology. Capabilities within each perspective identify the areas of your organization that require attention. From this information, you can build an action plan organized into prescriptive work streams that support a successful cloud journey. Both the CAF and 6 Rs frameworks help you understand and plan the broader context of an AWS migration and what it means to you and your company. # Planning Before you start migrating your SAP environment to AWS, there are some prerequisites that we recommend you go over, to ensure minimal interruptions or delays. For details, see the [SAP on AWS overview](https://docs.aws.amazon.com/sap/latest/general/sap-on-aws-overview.html). The following sections discuss additional considerations for planning your migration. ## Understanding On-Premises Resource Utilization If you are planning to rehost your on-premises SAP HANA environment on AWS, [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/) can help you understand the utilization of resources as well as hardware configuration, performance data, and network connections in your on-premises SAP HANA environment. You can use this information to ensure that appropriate communication ports are enabled between SAP HANA and other systems in the security groups or virtual private clouds (VPCs) on AWS. Application Discovery Service can be deployed in an agentless mode (for VMware environments) or with an agent-based mode (all VMs and physical servers). We recommend that you run Application Discovery Service for a few weeks to get a complete, initial assessment of how your on-premises environment is utilized, before you migrate to AWS. ## Reviewing AWS Automation Tools for SAP It is a good idea to review AWS automation tools and services that can help you migrate your SAP environment to AWS. For example, AWS Launch Wizard for SAP helps you deploy workloads, such as SAP HANA and SAP NetWeaver application servers. For details, see the [Migration Tools and Methodologies](migrating-hana-tools.md) section later in this guide. ## Prerequisites SAP HANA system migration requires a moderate to high-level knowledge of the source and target IT technologies and environments. We recommend that you familiarize yourself with the following information: AWS Cloud architecture and migration: + [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html) + [An Overview of the AWS Cloud Adoption Framework](https://d1.awsstatic.com/whitepapers/aws_cloud_adoption_framework.pdf) + [Architecting for the Cloud: Best Practices](https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf) + [Migrating Your Existing Applications to the AWS Cloud](https://d1.awsstatic.com/whitepapers/cloud-migration-main.pdf) AWS services: + [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/) + [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) + [Amazon Elastic Block Store (Amazon EBS)](https://aws.amazon.com/ebs/) + [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) SAP on AWS: + [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) + [SAP HANA Environment Setup on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html) # SAP HANA Sizing The size of the SAP HANA system required on the AWS Cloud depends on the migration scenario. As mentioned earlier, migrating SAP HANA to AWS involves two possible scenarios: rehosting or replatforming. ## Memory Requirements for Rehosting Because rehosting implies that you are already running SAP HANA, you can determine the size of the SAP HANA system you need on the AWS Cloud from the peak memory utilization of your existing SAP HANA system. You may have oversized your on-premises SAP HANA environment (for example, to support future growth), so measuring peak memory utilization is a better approach than measuring allocated memory. When you have determined the base memory requirement, you should choose the smallest SAP-certified EC2 instance that provides more memory than your base requirement. There are three ways to determine peak memory utilization of your existing SAP HANA system: + SAP HANA Studio: The overview tab of the SAP HANA Studio administration view provides a memory utilization summary. + SAP EarlyWatch alerts: This is a free, automated service from SAP that helps you monitor major administrative areas of your SAP system. See the [SAP portal](https://support.sap.com/en/offerings-programs/support-services/earlywatch-alert.html) for details. + SQL statements: SAP provides SQL statements that you can use to determine peak memory utilization. For details, see [SAP KBA 1999997 – FAQ: SAP HANA Memory](https://me.sap.com/notes/1999997) and [SAP Note 1969700 – SQL statement collection for SAP HANA](https://me.sap.com/notes/1969700). **Tip** We recommend determining peak memory utilization for a timeframe during which your system utilization is likely to be high (for example, during year-end processing or a major sales event). ## Memory Requirements for Replatforming The replatforming scenario involves two possibilities: + You are already running SAP HANA but you want to change your operating system—​for example, from Red Hat Enterprise Linux (RHEL) to SUSE Linux Enterprise Server (SLES) or the other way around—​when you migrate to the AWS Cloud, or you are migrating from an IBM POWER system to the x86 platform. In this case, you should size SAP HANA as described for the rehosting scenario. + You are migrating from *anyDB* to SAP HANA. There are multiple ways you can estimate your memory requirements: + SAP standard reports for estimation: This is the best possible approach and is based on standard sizing reports provided by SAP. For examples, see the following SAP Notes: + [1736976 – Sizing Report for BW on HANA](https://me.sap.com/notes/1736976) + [1637145 – SAP BW on HANA: Sizing SAP In-Memory Database](https://me.sap.com/notes/1637145) + [1872170 - Business Suite on HANA and S/4HANA sizing report](https://me.sap.com/notes/1872170) + [1736976 – Sizing Report for BW on HANA](https://me.sap.com/notes/1736976) + SQL statements: SAP provides scripts that you can run in your existing environment to get high-level SAP HANA sizing estimates. These scripts run SQL statements against your existing database to estimate SAP HANA memory requirements. For more information, see [SAP Note 1793345 - Sizing for SAP Suite on SAP HANA](https://me.sap.com/notes/1793345). + Rule of thumb: See the PDF attached to [SAP Note 1793345 - SAP HANA Sizing for SAP Suite on SAP HANA](https://me.sap.com/notes/1793345) for instructions on estimating SAP HANA memory requirements manually. Note that this will be a very rough and generic estimate. You should also consider the following SAP notes and Knowledge Base articles for SAP HANA sizing considerations: + [2388483 – How-To: Data Management for Technical Tables](https://me.sap.com/notes/2388483) + [1855041 – Sizing Recommendation for Master Node in BW-on-HANA](https://me.sap.com/notes/1855041) + [1702409 – HANA DB: Optimal number of scale out nodes for BW on HANA](https://me.sap.com/notes/1702409) ## Instance Sizing for SAP HANA AWS offers SAP-certified systems that are configured to meet the specific SAP HANA performance requirements. For more information, see [SAP Note 1943937 – Hardware Configuration Check Tool - Central Note](https://me.sap.com/notes/1943937), and [Amazon EC2 instances for SAP on AWS](https://docs.aws.amazon.com/sap/latest/general/ec2-instance-types-sap.html). After you have determined your SAP HANA sizing, you can map your requirements to the EC2 instance family sizes. That is, you map the maximum amount of memory required for each of your SAP HANA instances to the maximum amount of memory available for your desired EC2 instance type. You should also consider appropriate storage volume types and sizes to ensure optimal performance of the SAP HANA database. For best practices and recommendations for volume types and file system layout, see the [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html). **Note** Only production SAP HANA systems need to run on certified configurations that meet SAP HANA key performance indicators (KPIs). SAP provides more flexibility when running SAP HANA non-production systems. For more information, see [SAP HANA TDI – FAQ](https://www.sap.com/documents/2016/05/e8705aae-717c-0010-82c7-eda71af511fa.html) and [OSS Note 2271345](https://me.sap.com/notes/2271345) on the SAP website. ## Network Planning and Sizing You will need to consider network planning and sizing for the amount of data you will be transferring to AWS. Data transfer time depends on network bandwidth available to AWS and influences total downtime. Higher bandwidth helps with faster data transfer and helps reduce overall migration time. For non-production systems where downtime isn’t critical, you can use a smaller network pipe to reduce costs. Alternatively, to transfer extremely large data, you can use services like [AWS Snowball](https://aws.amazon.com/snowball/faqs/) for a physical (non-network) transport of data to AWS. We’ll discuss AWS Snowball more extensively later in this guide. As a guideline, you can use this formula to help estimate how long your network data transfer might take: (Total bytes to be transferred / Transfer rate per second) = Total transfer time in seconds For example, for a 1 TB SAP HANA appliance, the total bytes to be transferred is usually 50% of the memory, which would be 512 GB. The transfer rate per second is your network transfer rate—​if you had a 1 Gb [AWS Direct Connect](https://aws.amazon.com/directconnect/) connection to AWS, you could transfer up to 125 MB per second, and your total data transfer time would be: 512 GB / 125 MB per second = 4,096 seconds (or 1.1 hours) After you determine the amount of data you need to transfer and how much time you have available to transfer the files, you can determine the AWS connectivity options that best fit your cost, speed, and connectivity requirements. ## SAP HANA Scale-up and Scale-out AWS provides several types of EC2 instances for SAP HANA workloads. This gives you options for your SAP HANA scale-up and scale-out deployments. In a scale-up scenario, you utilize the compute, memory, network, and I/O capacity of a single EC2 instance. If you require more capacity, you can resize your instances to a different EC2 instance type. For example, if you’re using an R4 instance type and it becomes too small for your workload, you can change it to an R5, X1, or X1e instance type. The limitation is the maximum capacity of a single EC2 instance. In AWS, scale-up enables you to start with the smallest EC2 instance type that meets your requirements and grow as needed. If your requirements change or new requirements surface, you can easily scale up to meet the changing requirements. In a scale-out scenario, you add capacity to your SAP HANA system by adding new EC2 instances to the SAP HANA cluster. For example, once you reach the maximum memory capacity of a single EC2 instance, you can scale out your SAP HANA cluster and add more instances. AWS has certified SAP HANA scale-out clusters that support up to 100 TiB of memory. Please note that the minimum number of recommended nodes in an SAP HANA scale-out cluster can be as low as two nodes; for more information, see [SAP Note 1702409 - HANA DB: Optimal number of scale out nodes for BW on HANA](https://me.sap.com/notes/1702409). It’s likely that your sizing estimates will reveal the need to plan for a scale-out configuration before you start your SAP HANA migration. AWS gives you the ability to easily deploy SAP HANA scale-out configurations when you use the [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html). The following table illustrates example scale-up and scale-out sizing. | Scenario | Source configuration | Target configuration | | --- | --- | --- | | **Scale-up** | r5.8xlarge | r5.16xlarge | | **Scale-up** | r5.16xlarge | x2idn.16xlarge | | **Scale-up** | x2idn.32xlarge | x2iedn.32xlarge | | **Scale-out** | 3 nodes of x2idn.16xlarge | 4 nodes of x2idn.16xlarge | | **Scale-out** | x2idn.32xlarge | 3 nodes of x2idn.16xlarge | When you finalize your SAP sizing and SAP HANA deployment models, you can plan your migration strategy. In addition to SAP HANA sizing, you may also need to size your SAP application tier. To find the SAP Application Performance Standard (SAPS) ratings of SAP-certified EC2 instances, see [SAP Standard Application Benchmarks](https://www.sap.com/about/benchmark.html) and the [SAP on AWS support note](https://me.sap.com/notes/1656099) on the SAP website (SAP login required). # Migration Tools and Methodologies This section provides an introduction to the tools and methodologies available to you for your SAP system migration. **Topics** + [AWS Launch Wizard for SAP](#migrating-hana-launch-wizard) + [AWS Migration Hub Orchestrator](#migrating-hana-orchestrator) + [Amazon EC2 Instance Resize](#migrating-hana-instance-resize) + [AMIs](#migrating-hana-amis) + [AWS Snowball Edge](#migrating-hana-snowball) + [Amazon S3 Transfer Acceleration](#migrating-hana-s3-acceleration) + [SAP HANA HSR with Initialization via Backup and Restore](#migrating-hana-hsr-init) + [Migration Using DMO with System Move](#migrating-hana-dmo-sm) + [SAP HANA Classical Migration](#migrating-hana-classical) + [SAP Software SUM DMO](#migrating-hana-sum-dmo) + [DMO Move to SAP S/4HANA on AWS (single step) – DMOVE2S4](#migrating-hana-dmove2s4) + [Backup/Restore Tools](#migrating-hana-backup-restore) ## AWS Launch Wizard for SAP AWS Launch Wizard for SAP is a service that guides you through the sizing, configuration, and deployment of SAP applications on AWS, and follows [AWS cloud application best practices](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html). AWS Launch Wizard reduces the time it takes to deploy SAP applications on AWS. You input your application requirements, including SAP HANA settings, SAP landscape settings, and deployment details on the service console, and Launch Wizard identifies the appropriate AWS resources to deploy and run your SAP application. Launch Wizard provides an estimated cost of deployment, which allows you to modify your resources and instantly view the updated cost. When you finalize your settings, Launch Wizard provisions and configures the selected resources. It then optionally installs an SAP HANA database and supported SAP applications using customer-provided software. After you deploy an SAP application, you can access it from the Amazon EC2 console. You can manage your SAP applications with AWS SSM. For more information, see [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html). ## AWS Migration Hub Orchestrator AWS Migration Hub Orchestrator simplifies and automates the migration of servers and enterprise applications to AWS. It provides a single location to run and track your migrations. You can migrate SAP HANA scale-up and scale-out systems to AWS cloud with AWS Migration Hub Orchestrator. Migration Hub Orchestrator offers templates to create a migration workflow that can be customized to fit your unique migration requirements. For more information, see [AWS Migration Hub Orchestrator?](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/what-is-migrationhub-orchestrator.html) You can access AWS Migration Hub Orchestrator from link: [https://console.aws.amazon.com/migrationhub/orchestrator/](https://console.aws.amazon.com/migrationhub/orchestrator/) or from the AWS Command Line Interface. ## Amazon EC2 Instance Resize Amazon EC2 provides you with the ability to easily change your instance type in minutes, from the Amazon EC2 console, the AWS Command Line Interface (AWS CLI), or the Amazon EC2 API. You can start with an instance type that meets your current needs and size your instance up or down, when your requirements change. When you change your EC2 instance type, all instance metadata, including the IP address, instance ID, and hostname, remains the same. This enables you to migrate your SAP HANA to a new instance type seamlessly, without incurring a longer downtime. For details, see the [Changing the Instance Type](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html) in the Amazon EC2 documentation. ## AMIs You can use an Amazon Machine Image (AMI) to launch any EC2 instance. You can create an AMI of an EC2 instance that hosts SAP HANA, including the attached EBS volumes, through the Amazon EC2 console, the AWS CLI, or the Amazon EC2 API. You can then use the AMI to launch a new EC2 instance with SAP HANA in any Availability Zone within the AWS Region where the AMI was created. You can also copy your AMI to another AWS Region and use it to launch a new instance. You can use this feature to move your SAP HANA instance to another Availability Zone or AWS Region, or to change the tenancy type of your EC2 instance. For example, you can create an AMI of your EC2 instance with default tenancy and use it to launch a new EC2 instance with host or dedicated tenancy and vice versa. For details, see the [Amazon Machine Images (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html) in the Amazon EC2 documentation. ## AWS Snowball Edge With AWS Snowball Edge, you can copy large amounts of data from your on-premises environment to AWS, when it’s not practical or possible to copy the data over the network. AWS Snowball Edge is a storage appliance that is shipped to your data center. You plug it into your local network to copy large volumes of data at high speed. When your data has been copied to the appliance, you can ship it back to AWS, and your data will be copied to Amazon S3 based on the desired target storage destination that you specify. AWS Snowball Edge is very useful when you’re planning very large, multi-TB SAP system migrations. For more information, see *When should I consider using Snowball instead of the Internet* in the [AWS Snowball Edge FAQ](https://aws.amazon.com/snowball/faqs/). ## Amazon S3 Transfer Acceleration Amazon S3 Transfer Acceleration provides a faster way to copy data from your on-premises environment to AWS by copying data first to Amazon CloudFront edge locations that are closest to the source, and then using an optimized network path to copy data to Amazon S3. There is a network charge associated with this type of transfer. You can run an AWS-provided [test tool](https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/en/accelerate-speed-comparsion.html) to compare the speed of Amazon S3 Transfer Acceleration to standard Amazon S3 data transfer. For SAP workloads, you can copy backups or DB logs at regular intervals over Amazon S3 Transfer Acceleration to reduce the transfer time, if your regular network connection is slow—​for example, if your SAP environment is hosted in a location that doesn’t have very strong internet connectivity. For more information, see the [Amazon S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/dev/transfer-acceleration.html). ## SAP HANA HSR with Initialization via Backup and Restore SAP supports the option of initializing the HSR target system with a backup and restore process. Using backup and restore can be useful if the network connection between your source SAP HANA system and the target system does not have enough bandwidth to replicate the data in a timely manner. Additionally, you may not want the data replication to consume part of your network traffic bandwidth. For details, see [SAP Note 1999880 – FAQ: SAP HANA System Replication](https://me.sap.com/notes/1999880). ## Migration Using DMO with System Move SAP has enhanced the database migration option (DMO) of their Software Update Manager (SUM) tool to accelerate the testing of SAP application migrations. DMO with System Move enables you to migrate your SAP system from your on-premises environment to AWS by using a DMO tool and a special export and import process. You can use AWS services such as Amazon S3, Amazon EFS (over AWS Direct Connect), Storage Gateway file interface, and AWS Snowball Edge to transfer your SAP export files to AWS. You can then use the AWS Launch Wizard for SAP to rapidly provision SAP HANA instances and build your SAP application servers on AWS, when you are ready to trigger the import process of the DMO tool. The SUM DMO tool can convert data from *anyDB* to SAP HANA or SAP ASE, with OS migrations, release/enhancement pack upgrades, and Unicode conversions occurring at the same time. Results are written to flat files, which are transferred to the target SAP HANA system on AWS. The second phase of DMO with System Move imports the flat files and builds the migrated SAP application with the extracted data, code, and configuration. Here’s a conceptual flow of the major steps involved: ![\[Diagram of the SUM DMO tool.\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-dmo-sm.png) ## SAP HANA Classical Migration SAP offers the SAP HANA classical migration option for migrating from other database systems to SAP HANA. This option uses the SAP heterogeneous system copy process and tools. To copy the exported files, you can use the options described in the [Backup/Restore Tools](#migrating-hana-backup-restore) section later in this guide. For details on the classical migration approach, see the [classical migration overview](https://community.sap.com/t5/-/-/m-p/13264529) on the SAP website. ## SAP Software SUM DMO SAP offers the standard SUM DMO approach as a one-step migration option from other database systems to HANA. This option uses the SAP DMO process and tool to automate multiple required migration steps. This is a preferred option if you are already running SAP on *anyDB* on AWS, as it will improve your migration times to SAP HANA, since there is no need for data export/import at a file system level. For details, see the [DMO of SUM overview](https://community.sap.com/t5/technology-blog-posts-by-sap/database-migration-option-dmo-of-sum-introduction/ba-p/13262160) on the SAP website. ## DMO Move to SAP S/4HANA on AWS (single step) – DMOVE2S4 Using SAP Database Migration Option (DMO) feature DMOVE2S4, you can migrate SAP ECC on SAP HANA or any other database, such as Oracle, SQL or others hosted on-premises to AWS Cloud. It combines migration with conversion. With this option, you can convert SAP ERP on SAP HANA to SAP S/4HANA while migrating the system to SAP S/4HANA cloud, private edition on AWS Cloud. The migration is performed over network, using memory pipe option. It eliminates the requirement to import/export data over file system. You can further accelerate the migration by using one or both of the following options. + Use AWS Direct Connect to enable secure and fast data transfer over the network. For more information, see [What is AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)? + Use an Amazon EC2 instance with a high number of vCPUs as the SAP application server running the import. This increases the parallel processing rate of the database load and reduces the time taken for migration and conversion. One of the biggest advantages of a heterogeneous migration is that you can use DMO features, downtime optimized techniques, such as downtime optimized DMO (doDMO) or downtime optimized conversion (DOC), that are not available when using traditional DMO with system move option. For more information, see the following SAP resources. + [SAP Note 3296427 - Database Migration Option (DMO) of SUM 2.0 SP17](https://me.sap.com/notes/3296427https://me.sap.com/notes/3296427) (requires SAP portal access) + [SAP Documentation - DMO Move to SAP S/4HANA (on Hyperscaler)](https://help.sap.com/docs/SLTOOLSET/7d57e56e12104cc68bce7646cd9f4cbf/c17f45ffa4004ca4837913a745b3a081.html) ![\[Diagram of DMO Move to SAP S/4HANA (single step) – DMOVE2S4.\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/DMOVE2S4.png) ## Backup/Restore Tools Backup and restore options are tried-and-true mechanisms for saving data on a source system and restoring it to another destination. AWS has various storage options available to help facilitate data transfer to AWS. Some of those are explained in this section. We recommend that you discuss which option would work best for your specific workload with your systems integrator (SI) partner or with an AWS solutions architect. + Storage Gateway: This is a virtual appliance installed in your on-premises data center that helps you replicate files, block storage, or tape libraries by integrating with AWS storage services such as Amazon S3 and by using standard protocols like Network File system (NFS) or Internet Small Computer System Interface (iSCSI). Storage Gateway offers file-based, volume-based, and tape-based storage solutions. For SAP systems, we will focus on file replication using a file gateway and block storage replication using a volume gateway. For scenarios where multiple backups or logs need to be continuously copied to AWS, you can copy these files to the locally mounted storage and they will be replicated to AWS. ![\[Diagram of Storage Gateway.\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-storage-gateway.png) + Amazon EFS file transfer: AWS provides options to copy data from an on-premises environment to AWS by using Amazon Elastic File System (Amazon EFS). Amazon EFS is a fully managed service, and you pay only for the storage that you use. You can mount an Amazon EFS file share on your on-premises server, as long as you have AWS Direct Connect set up between your corporate data center and AWS. ![\[Diagram of Amazon EFS file transfer.\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-efs.png) # Migration Scenarios The following table lists the migration scenarios that we will cover in detail in this guide. The tools and methodologies listed in the table were discussed in the [previous section](migrating-hana-tools.md). | Migration scenario | Source database | Target database | Migration tool or methodology | | --- | --- | --- | --- | | **Migration of anyDB from other platforms to AWS **\$1 | *anyDB* (any non-SAP HANA database such as IBM DB2, Oracle Database, or SQL Server) | SAP HANA | SAP HANA classical migration SAP DMO with System Move SAP DMO move to SAP S/4 HANA (on hyperscaler) DMOVE2S4 | | **Migration of SAP HANA from other platforms to AWS **\$1 | SAP HANA (scale-up and scale-out considerations apply here as well) | SAP HANA | AWS Migration Hub Orchestrator SAP HANA backup and restore SAP HANA classical migration (considered a homogeneous system copy in this scenario)\$1\$1 SAP HANA HSR SAP HANA HSR with initialization via backup and restore SAP DMO with system move SAP DMO move to SAP S/4 HANA (on hyperscaler) DMOVE2S4 | | **Migration of SAP HANA from an existing EC2 instance to an EC2 High Memory instance** | SAP HANA | SAP HANA | Instance resize Amazon Machine Image (AMI) SAP HANA HSR AWS Migration Hub Orchestrator SAP HANA backup and restore | **\$1**\$1 Other platforms include on-premises infrastructures and other cloud infrastructures outside of AWS. **\$1**\$1\$1 See [SAP Note 1844468 – Homogeneous system copy on SAP HANA](https://me.sap.com/notes/1844468). # Migrating *AnyDB* to SAP HANA on AWS Migrating from *anyDB* to HANA typically involves changes to the database platform and sometimes includes operating system changes. However, migration might also involve additional technical changes and impacts, such as the following: + SAP ABAP code changes. For example, you might have custom code that has database or operating system dependencies, such as database hints coded for the *anyDB* platform. You might also need to change custom ABAP code so it performs optimally on SAP HANA. See SAP’s recommendations and guidance for these SAP HANA-specific optimizations. For details and guidance, see [Get started with the ABAP custom code migration process](https://community.sap.com/t5/-/-/m-p/13531886) and SAP Notes [1885926 – ABAP SQL monitor](https://me.sap.com/notes/1885926) and [1912445 – ABAP custom code migration for SAP HANA](https://me.sap.com/notes/1912445) on the SAP website. + Operating system-specific dependencies such as custom file shares and scripts that would need to be re-created or moved to a different solution. + Operating system tunings (for example, kernel parameters) that would need to be accounted for. Note that the [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) incorporates best practices from operating system partners like SUSE and Red Hat for SAP HANA. + Technology expertise such as Linux administration and support, if your organization doesn’t already have experience with Linux. SAP provides tools and methodologies such as classical migration and SUM DMO to help its customers with the migration process for this scenario. (For more information, see the section [Migration Tools and Methodologies](migrating-hana-tools.md).) AWS customers can use the [SAP SUM DMO tool](migrating-hana-tools.md#migrating-hana-sum-dmo) to migrate their database to SAP HANA on AWS. Some considerations for the SAP SUM DMO method are network bandwidth, amount of data to be transferred, and the amount of time available for the data to be transferred. You can use the SUM DMO memory pipe option – DMO Move to SAP S/4HANA (DMOVE2S4) to accelerate your move to SAP S/4HANA. In a single step, you can migrate the database over network while converting to SAP S/4HANA. For more information, see SAP Documentation – [DMO Move to SAP S/4HANA (on Hyperscaler)](https://help.sap.com/docs/SLTOOLSET/7d57e56e12104cc68bce7646cd9f4cbf/c17f45ffa4004ca4837913a745b3a081.html). Use [AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html) to connect your on-premises environment with AWS Cloud for secure and fast data transfer over the network. When using DMOVE2S4, you must take the following into consideration. + low latency – less than 20 ms + high bandwidth – more than 400 Mbps For more information, see the following SAP resources. + [SAP Note 3296427 - Database Migration Option (DMO) of SUM 2.0 SP17](https://me.sap.com/notes/3296427https://me.sap.com/notes/3296427) (requires SAP portal access) + [SAP Blog - Two Major News with SUM 2.0 SP 17](https://community.sap.com/t5/-/-/m-p/13548361) Implementing SAP HANA on AWS enables quick provisioning of scale-up and scale-out SAP HANA configurations and enables you to have your SAP HANA system available in minutes. In addition to fast provisioning, AWS lets you quickly scale up by changing your EC2 instance type. With this capability, you can react to changing requirements promptly and focus less on getting your sizing absolutely perfect. This means that you can spend less time sizing (that is, you can move through your project’s planning and sizing phase faster) knowing that you can scale up later, if needed. # Migrating SAP HANA from Other Platforms to AWS This scenario is more straightforward than migrating from *anyDB*, because you’re already using SAP HANA. For this migration, you need to map your existing SAP HANA systems and sizing that are on a different platform to SAP HANA solutions on AWS. EC2 instance memory capabilities give you the option to consolidate multiple SAP HANA databases on a single EC2 instance (scale-up) or multiple EC2 instances (scale-out). SAP calls these options HANA and ABAP One Server, Multiple Components in One Database (MCOD), Multiple Components in One System (MCOS), and Multitenant Database Containers (MDC). It is beyond the scope of this guide to recommend specific consolidation combinations; for possible combinations, see [SAP Note 1661202 – Support for multiple applications on SAP HANA](https://me.sap.com/notes/1661202). This migration scenario involves provisioning your SAP HANA system on AWS, backing up your source database, transferring your data to AWS, and installing your SAP application servers. If you are resizing your HANA environment from scale-up to scale-out, please follow the process highlighted in [SAP Note 2130603](https://me.sap.com/notes/0002130603). If you are resizing your HANA environment from scale-out to scale-up, refer to [SAP Note 2093572](https://me.sap.com/notes/2093572). Depending on your specific scenario, you can use standard backup and restore, SAP HANA classical migration, SAP HANA HSR, AWS Server Migration Service (AWS SMS), or third-party continuous data protection (CDP) tools; see the following sections for details on each option. **Topics** + [Option 1: AWS Migration Hub Orchestrator](#migrating-hana-mhub-orchestrator) + [Option 2: SAP HANA Backup and Restore](#migrating-hana-backup-restore-steps) + [Option 3: SAP HANA Classical Migration](#migrating-hana-classical-steps) + [Option 4: SAP HANA HSR](#migrating-hana-hsr-steps) + [Option 5: SAP HANA HSR (with Initialization via Backup and Restore)](#migrating-hana-hsr-with-backup-restore-steps) + [Option 6: SAP HANA (on-premises) to SAP HANA (AWS Cloud)](#migrating-hana-on-premises-cloud) ## Option 1: AWS Migration Hub Orchestrator For details on how to migrate SAP HANA systems to AWS using AWS Migration Hub Orchestrator, see [Migrate SAP NetWeaver based applications and SAP HANA databases to AWS](https://docs.aws.amazon.com/migrationhub-orchestrator/latest/userguide/migrate-sap.html). ![\[Diagram of Option 1: Migration Hub Orchestrator\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/hana-mho.png) ## Option 2: SAP HANA Backup and Restore ![\[Diagram of Option 2: SAP HANA Backup and Restore\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-backup-restore.png) 1. Provision your SAP HANA system and landscape on AWS. (The [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) can help expedite and automate this process for you.) 1. Transfer (**sftp** or **rsync**) a full SAP HANA backup, making sure to transfer any necessary SAP HANA logs for point-in-time recovery, from your source system to your target EC2 instance on AWS. A general tip here is to compress your files and split your files into smaller chunks to parallelize the transfer. If your transfer destination is Amazon S3, using the **aws s3 cp** command will automatically parallelize the file upload for you. For other options for transferring your data to AWS, see the AWS services listed previously in the [Backup/Restore Tools](migrating-hana-tools.md#migrating-hana-backup-restore) section. 1. Recover your SAP HANA database. 1. Install your SAP application servers. (Skip this step if you used the [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) in step 1.) 1. Depending on your application architecture, you might need to reconnect your applications to the newly migrated SAP HANA system. ## Option 3: SAP HANA Classical Migration ![\[Diagram of Option 3: SAP HANA Classical Migration\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-classical.png) 1. Provision your SAP HANA system and landscape on AWS. (The [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) can help expedite and automate this process for you.) 1. Perform an SAP homogeneous system copy to export your source SAP HANA database. You may also choose to use a database backup as the export; see [SAP Note 1844468 – Homogeneous system copy on SAP HANA](https://me.sap.com/notes/1844468). When export is complete, transfer your data into AWS. 1. Continue the SAP system copy process on your SAP HANA system on AWS to import the data you exported in step 2. 1. Install your SAP application servers. (Skip this step if you used the [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) in step 1.) 1. Depending on your application architecture, you might need to reconnect your applications to the newly migrated SAP HANA system. ## Option 4: SAP HANA HSR ![\[Diagram of Option 4: SAP HANA HSR\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-hsr.png) 1. Provision your SAP HANA system and landscape on AWS. ([AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) can help expedite and automate this process for you.) To save costs, you might choose to stand up a smaller EC2 instance type. 1. Establish asynchronous SAP HANA system replication from your source database to your standby SAP HANA database on AWS. 1. Perform an SAP HANA takeover on your standby database. 1. Install your SAP application servers. (Skip this step if you used [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) in step 1.) 1. Depending on your application architecture, you might need to reconnect your applications to the newly migrated SAP HANA system. ## Option 5: SAP HANA HSR (with Initialization via Backup and Restore) ![\[Diagram of Option 5: SAP HANA HSR (with Initialization via Backup and Restore)\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-hsr-plus.png) 1. Provision your SAP HANA system and landscape on AWS. ([AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) can help expedite and automate this process for you.) To save costs, you might choose to stand up a smaller EC2 instance type. 1. Stop the source SAP HANA database and obtain a copy of the data files (this is essentially a cold backup). After the files have been saved, you may start up your SAP HANA database again. 1. Transfer the SAP HANA data files to AWS, to the SAP HANA server you provisioned in step 1. (For example, you can store the data files in the /backup directory or in Amazon S3 during the transfer process.) 1. Stop the SAP HANA database on the target system in AWS. Replace the SAP HANA data files (on the target server) with the SAP HANA data files you transferred in step 3. 1. Start the SAP HANA system on the target system and establish asynchronous SAP HANA system replication from your source system to your target SAP HANA system in AWS. 1. Perform an SAP HANA takeover on your standby database. 1. Install your SAP application servers. (Skip this step if you used [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) in step 1.) 1. Depending on your application architecture, you might need to reconnect your applications to the newly migrated SAP HANA system. ## Option 6: SAP HANA (on-premises) to SAP HANA (AWS Cloud) SAP added a new feature to the DMO option with SUM 2.0 SP-17 – DMO with system move, enabling SAP HANA to SAP HANA migration. It combines migration with conversion. With this option, you can convert SAP ERP on SAP HANA to SAP S/4HANA while migrating the system to SAP S/4HANA cloud, private edition on AWS Cloud. DMOVE2S4 enables homogeneous migration (SAP HANA to SAP HANA). For this scenario, downtime optimized techniques, such as downtime optimized DMO (doDMO) or downtime optimized conversion (DOC) are currently not supported. For more information, see SAP Blog - [Two Major News with SUM 2.0 SP 17](https://community.sap.com/t5/-/-/m-p/13548361). The following image displays this option. ![\[Diagram of Option 6: SAP HANA (on-premises) to SAP HANA\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/option6-hanatohana.png) # Migrating SAP HANA on AWS to an EC2 High Memory Instance EC2 High Memory instances are built on [AWS Nitro System](https://aws.amazon.com/ec2/nitro) with up to 24TB of memory in a single instance to deliver scalable and elastic infrastructure capabilities for large in-memory databases, such as SAP HANA. For SAP HANA workloads, EC2 High Memory instances support SUSE Linux Enterprise Server for SAP Applications (SLES for SAP) and Red Hat Enterprise Linux for SAP Solutions (RHEL for SAP) operating systems. The following table provides the minimum supported operating system version for SAP HANA workloads. See the [SAP HANA hardware directory](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23) for a list of supported operating systems for your instance type. | Instance Type | Supported operating system version | | --- | --- | | u-6tb1.metal, u-9tb1.metal, and u-12tb1.metal | SLES for SAP 12 SP3 and above; RHEL for SAP 7.4 and above | | u-18tb1.metal and u-24tb1.metal | SLES for SAP 12 SP4 and above; RHEL for SAP 8.1 and above | | u-3tb1.56xlarge | SLES for SAP 12 SP3 and above; RHEL for SAP 7.4 and above | | u-6tb1.56xlarge | SLES for SAP 12 SP3 and above; RHEL for SAP 7.4, RHEL for SAP 7.7 and above | | u-6tb1.112xlarge, u-9tb1.112xlarge, u-12tb1.112xlarge, u-18tb1.112xlarge, and u-24tb1.112xlarge | SLES for SAP 12 SP4 and above; RHEL for SAP 8.1 and above | | u7i-6tb.112xlarge, u7i-8tb.112xlarge, u7i-12tb.224xlarge, u7in-16tb.224xlarge, u7in-24tb.224xlarge, and u7inh-32tb.480xlarge | SLES 15 SP3 and above; RHEL 8.6 and above | **Considerations** **u-\$1tb1.112xlarge** Before using `u-*tb1.112xlarge` instance types with one of the following operating system versions, verify that your system has the minimum required kernel version in order to use all available vCPUs. + SLES for SAP 12 SP4 – 4.12.14-95.68 + SLES for SAP 12 SP5 – 4.12.14-122.60 + SLES for SAP 15 – 4.12.14-150.66 + SLES for SAP 15 SP1 – 4.12.14-197.83 + SLES for SAP 15 SP2 – 5.3.18-24.52 + RHEL for SAP 8.1 - 4.18.0-147.44.1.el8\$11 + RHEL for SAP 8.2 - 4.18.0-193.47.1.el8\$12 **u-\$1tb1.metal** You must launch `u-tb1.metal ` instances using Amazon EC2 Dedicated Hosts with host tenancy. `u7i`, `u-6tb1.56xlarge`, and `u-*tb1.112xlarge` instances can be launched with default, dedicated or host tenancy. Before you start your migration, if you plan to use `u-tb1.metal ` instances, make sure that an `u-*tb1.metal` instance is allocated to your target account, Availability Zone, and AWS Region. If you plan to use `u7i`, `u-6tb1.56xlarge` or `u-*tb1.112xlarge`, ensure your account limit for resource "On-Demand High Memory instances" or "U\$1TB1 Dedicated Hosts" (required only if you intend to use it as dedicated host) is set appropriately. If needed, submit a request from AWS console to increase your account limit. For more information, see [Amazon EC2 service quotas and On-Demand Instance limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) in the *Amazon EC2 User Guide*. **u7inh-32tb.480xlarge** If you use the `u7inh-32tb.480xlarge` instance type to run the SAP S/4HANA application, you must disable Hyperthreading for best performance. `u7inh-32tb.480xlarge` has 16 CPU sockets and SAP requires Hyperthreading to be disabled for Intel Sapphire Rapids based 16-socket systems. If you are running analytical workloads such as SAP BW/4HANA, you don’t have to disable Hyperthreading. For additional details, see SAP Note 2711650. You can disable Hyperthreading by setting threads per core to 1 using the CPU options feature. For more information, see [Specify CPU options for an Amazon EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-specify-cpu-options.html) in the *Amazon EC2 User Guide*. You have several options for migrating your existing SAP HANA workload on AWS to an EC2 High Memory instance, as discussed in the following sections. In the following sections, we show X1 instance as the source instance type for migration. These procedures are applicable for any other source instance types as well. **Topics** + [Option 1: Resizing an Existing EC2 Instance with Host or Dedicated Tenancy](#migrating-hana-hm-resize) + [Option 2: Migrating from an Existing EC2 Instance with Default Tenancy](#migrating-hana-hm-default) + [Option 3: Migrating from Amazon EC2 High Memory metal instance with Virtualized High Memory Host Tenancy](#migrating-hana-high-memory) ## Option 1: Resizing an Existing EC2 Instance with Host or Dedicated Tenancy If your existing EC2 instance is running with host or dedicated tenancy, you can follow the steps in this section to migrate it to `u-\$1tb1.metal ` EC2 High Memory instance. With this option, all your instance properties, including IP addresses, hostnames, and EBS volumes, remain the same after migration. ![\[Diagram of Option 1: Resizing an Existing EC2 Instance with Host or Dedicated Tenancy\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-hm-resize.png) 1. Verify that your source system is running on a supported operating system version. If not, you might have to upgrade your operating system before resizing to an EC2 High Memory instance. 1. EC2 High Memory instances are based on the Nitro system. On Nitro-based instances, EBS volumes are presented as NVMe block devices. If your source system has any mount point entries in `/etc/fstab` with reference to block devices such as `/dev/xvd`, you need to create a label for these devices and mount them by label before migrating to EC2 High Memory instances. Otherwise, you will face issues when you start SAP HANA on an EC2 High Memory instance. 1. Verify that you don’t exceed the maximum supported EBS volumes to your instance. An `u-tb1.metal ` EC2 High Memory instance currently supports up to 19 EBS volumes. `u7i`, `u-6tb1.56xlarge`, and `u-*tb1.112xlarge` instances supports up to 27 EBS volumes. For details, see [Instance Type Limits](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html#instance-type-volume-limits) in the AWS documentation. 1. When you are ready to migrate, make sure that you have a good backup of your source system. You can use AWS Backint Agent for SAP HANA to easily backup your SAP HANA database to Amazon S3. For details, see [AWS Backint Agent for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html) in the AWS documentation. 1. Stop the source instance in the Amazon EC2 console or by using the AWS CLI. 1. If your source EC2 instance is running with dedicated tenancy, modify the instance placement to host tenancy. For instructions, see [Modifying instance Tenancy and Affinity](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/how-dedicated-hosts-work.html#moving-instances-dedicated-hosts) in the AWS documentation. Skip this step if your instance is running with host tenancy. 1. Modify the instance placement of your existing instance to your target EC2 High Memory Dedicated Host through the Amazon EC2 console or the AWS CLI. For details, see [modify-instance-placement](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-placement.html) in the AWS documentation. 1. Change your instance type to the desired EC2 High Memory instance type (for example, `u-12tb1.metal` or `u-12tb1.112xlarge`) through the AWS CLI or AWS Console. **Note** You can change the instance type to `u-*tb1.metal` only through the AWS CLI or Amazon EC2 API. 1. Start your instance in the Amazon EC2 console or by using the AWS CLI. 1. When you increase the memory of your SAP HANA system, you might need to adjust the storage size of SAP HANA data, log, shared, and backup volumes as well to accommodate data growth and to get improved performance. For details, see [SAP HANA on AWS Operations Guide](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-operations.html). 1. Start your SAP HANA database and perform your validation. 1. Complete any SAP HANA-specific post-migration activities. 1. Complete any AWS-specific post-migration activities, such as setting up Amazon CloudWatch, AWS Config, and AWS CloudTrail. 1. Configure your SAP HANA system for high availability on the EC2 High Memory instance with SAP HANA HSR and clustering software, and test it. 1. Complete post-migration tasks to ensure that you are not charged. + Review and confirm if you need to cancel reservations once migration is complete. + Review and confirm if you need to release Amazon EC2 Dedicated Hosts through the console. Once a reservation is cancelled, on-demand charging begins for the dedicated hosts until they are released from the console. ## Option 2: Migrating from an Existing EC2 Instance with Default Tenancy If your existing EC2 instance is running with default tenancy, you have multiple options to migrate it to an EC2 High Memory instance: If you plan to use `u7i*`, `u-6tb1.56xlarge` or `u-*tb1.112xlarge` instance types, you can simply stop your instance and resize it to desired target instance size. Additionally, if you plan to use `u-*tb1.metal` instances, you can use an Amazon Machine Image (AMI) to launch your `u-*tb1.metal` EC2 High Memory instance with host tenancy, or you can set up a new SAP HANA on EC2 High Memory instance and then copy the data over from your source system. ### Option 2(a): Resizing an existing EC2 instance In this option, if you are using `u7i*`, `u-6tb1.56xlarge` or `u-*tb1.112xlarge` instance types, you can simply resize your instance through AWS Management Console or AWS CLI. ![\[Diagram of Option 2(a): Resizing an existing EC2 instance\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-hm-ec2.png) 1. Verify that your source system is running on a supported operating system version. If it isn’t, you might have to upgrade your operating system before resizing to an EC2 High Memory instance. 1. EC2 High Memory instances are based on the Nitro system. On Nitro-based instances, EBS volumes are presented as NVMe block devices. If your source system has any mount point entries in `/etc/fstab` with reference to block devices such as `/dev/xvd`, you need to create a label for these devices and mount them by label before migrating to EC2 High Memory instances. Otherwise, you will face issues when you start SAP HANA on an EC2 High Memory instance. 1. When you are ready to migrate, verify that you have a good backup of your source system. 1. Stop the source instance in the Amazon EC2 console or by using the AWS CLI. 1. Change the instance type to target EC2 High Memory instance size such as `u7i*`, `u-6tb1.56xlarge` or `u-*tb1.112xlarge`. 1. When you increase the memory of your SAP HANA system, you might need to adjust the storage size of SAP HANA data, log, shared, and backup volumes as well to accommodate data growth and to get improved performance. For details, see the [SAP HANA on AWS Operations Guide](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-operations.html). 1. Start your SAP HANA database and perform your validation. **Note** If necessary, complete any SAP HANA-specific post-migration activities. 1. Check the connectivity between your SAP application servers and the new SAP HANA instance. 1. If necessary, complete any AWS-specific post-migration activities, such as setting up Amazon CloudWatch, AWS Config, and AWS CloudTrail. 1. Configure your SAP HANA system for high availability on the EC2 High Memory instance with SAP HANA HSR and clustering software, and test it. 1. Complete post-migration tasks to ensure that you are not charged. + Review and confirm if you need to cancel reservations once migration is complete. + Review and confirm if you need to release Amazon EC2 Dedicated Hosts through the console. Once a reservation is cancelled, on-demand charging begins for the dedicated hosts until they are released from the console. ### Option 2(b): Migrating Using an AMI In this option, you launch a new EC2 High Memory instance based on the AMI that you created from your source system for the migration. ![\[Diagram of Option 2(b): Migrating Using an AMI\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-hm-ami.png) 1. Verify that your source system is running on a supported operating system version. If it isn’t, you might have to upgrade your operating system before resizing to an EC2 High Memory instance. 1. EC2 High Memory instances are based on the Nitro system. On Nitro-based instances, EBS volumes are presented as NVMe block devices. If your source system has any mount point entries in `/etc/fstab` with reference to block devices such as `/dev/xvd`, you need to create a label for these devices and mount them by label before migrating to EC2 High Memory instances. Otherwise, you will face issues when you start SAP HANA on an EC2 High Memory instance. 1. When you are ready to migrate, verify that you have a good backup of your source system. 1. Stop the source instance in the Amazon EC2 console or by using the AWS CLI. 1. Create an AMI of your source instance. For details, see [Creating an Amazon EBS-Backed Linux AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html) in the AWS documentation. **Tip** Creating an AMI for the first time with the attached EBS volumes could take a long time, depending on your data size. To expedite this process, we recommend that you take snapshots of EBS volumes attached to the instance ahead of time. 1. Launch a new EC2 High Memory instance with host tenancy for `u7i*` or `u-tb1.metal ` instances. For `u7i`, `u-6tb1.56xlarge`, and `u-*tb1.112xlarge`, you can launch a new EC2 High Memory instance with default, dedicated or host tenancy. 1. The new instance will have a new IP address. Update all references to the IP address of the source system, including the /etc/hosts file for the operating system and DNS entries, to reflect the new IP address. The hostname and storage layout will remain the same as on the source system. 1. When you increase the memory of your SAP HANA system, you might need to adjust the storage size of SAP HANA data, log, shared, and backup volumes as well to accommodate data growth and to get improved performance. For details, see the [SAP HANA on AWS Operations Guide](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-operations.html). 1. Start your SAP HANA database and perform your validation. **Note** You might notice that SAP HANA is slow when loading data into memory for the first time after you create your instance with an AMI. This is expected behavior when EBS volumes associated with SAP HANA data are created from a snapshot. You will not experience the slowness after the initial hydration. 1. Complete any SAP HANA-specific post-migration activities. 1. Check the connectivity between your SAP application servers and the new SAP HANA instance. 1. Complete any AWS-specific post-migration activities, such as setting up Amazon CloudWatch, AWS Config, and AWS CloudTrail. 1. Configure your SAP HANA system for high availability on the EC2 High Memory instance with SAP HANA HSR and clustering software, and test it. 1. Complete post-migration tasks to ensure that you are not charged. + Review and confirm if you need to cancel reservations once migration is complete. + Review and confirm if you need to release Amazon EC2 Dedicated Hosts through the console. Once a reservation is cancelled, on-demand charging begins for the dedicated hosts until they are released from the console. ### Option 2(c): Migrating Using SAP HANA HSR or SAP HANA backup and restore In this option, you launch a new EC2 High Memory instance, install and configure SAP HANA on the instance, and then copy the data over from your source system to complete the migration. 1. Launch a new SAP HANA EC2 High Memory instance with host tenancy for `u7i*` or `u-tb1.metal ` instances. For `u7i`, `u-6tb1.56xlarge`, and `u-*tb1.112xlarge`, you can launch your instance with default, dedicated or host tenancy. You can use the [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html) to set up your instance automatically, or follow the [SAP HANA Environment Setup on AWS](https://docs.aws.amazon.com/sap/latest/sap-hana/std-sap-hana-environment-setup.html) guide to set up your instance manually. Make sure that you are using an operating system that supports EC2 High Memory instances. 1. Complete any AWS-specific post-migration activities, such as setting up Amazon CloudWatch, AWS Config, and AWS CloudTrail, ahead of time. 1. Migrate the data from your existing SAP HANA instance by using SAP HANA HSR or SAP HANA backup and restore tools. + If you plan to use SAP HANA HSR for data migration, configure HSR to move data from your source system to your target system. For details, see the [SAP HANA Administration Guide](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/330e5550b09d4f0f8b6cceb14a64cd22.html) from SAP. ![\[Diagram of Option 2(c): Migrating Using SAP HANA HSR or SAP HANA backup and restore\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-hm-tools.png) + If you plan to use the SAP HANA backup and restore feature to migrate your data, back up your source SAP HANA system. When backup is complete, move the backup data to your target system and perform a restore in your target system. If you back up your source SAP HANA system directly to Amazon S3 using AWS Backint Agent for SAP HANA, you can directly restore it in the target system from Amazon S3. For details, see the [AWS Backint Agent for SAP HANA](https://docs.aws.amazon.com/sap/latest/sap-hana/aws-backint-agent-sap-hana.html) in the AWS documentation. ![\[Diagram of the SAP HANA backup and restore feature.\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-hana-hm-s3.png) 1. Stop your source system, complete any additional post-migration steps, like updating DNS and checking the connectivity between your SAP application servers and the new SAP HANA instance. 1. Configure your SAP HANA system for high availability on the EC2 High Memory instance with SAP HANA HSR and clustering software, and test it. 1. Complete post-migration tasks to ensure that you are not charged. + Review and confirm if you need to cancel reservations once migration is complete. + Review and confirm if you need to release Amazon EC2 Dedicated Hosts through the console. Once a reservation is cancelled, on-demand charging begins for the dedicated hosts until they are released from the console. ## Option 3: Migrating from Amazon EC2 High Memory metal instance with Virtualized High Memory Host Tenancy If your existing Amazon EC2 High Memory metal instance (`u*-tb1.metal`) is running with host tenancy, you can easily migrate it to virtualized high memory instance `(u-tb.56xlarge` or `u-tb.112xlarge)`. Stop your instance to change the tenancy and instance type, and then resize it to the desired target virtualized High Memory instance size. This architecture of this option is as shown in the following image. ![\[Diagram of Option 3: Migrating from Amazon EC2 High Memory metal instance with Virtualized High Memory Host Tenancy.\]](http://docs.aws.amazon.com/sap/latest/sap-hana/images/migrating-option-3.png) 1. Verify that your source system is running on a supported operating system version. If not, you might have to upgrade your operating system before resizing to an EC2 High Memory instance. 1. If you built your source High Memory metal instance with AWS Marketplace based image, such as SLES for SAP or RHEL for SAP, ensure that your target virtualized High Memory instance size is listed as supported instance type in the AWS Marketplace product page of your chosen image. 1. When you are ready to migrate, make sure that you have a good backup of your source system. 1. Stop the source instance in the Amazon EC2 console or by using the AWS CLI. 1. Change the tenancy type from host to default using AWS CLI. For more information, see [Tenancy conversion](https://docs.aws.amazon.com/license-manager/latest/userguide/conversion-tenancy.html). 1. Change your instance type to target High Memory instance type, such as `u-tb.56xlarge` or `u-tb.112xlarge` through the AWS CLI or AWS Console. 1. When you increase the memory of your SAP HANA system, you might need to adjust the storage size of SAP HANA data, log, shared, and backup volumes as well to accommodate data growth and to get improved performance. For details, see [SAP HANA on AWS Operations Guide](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-operations.html). 1. Enable Amazon EC2 automatic recovery to recover your instance when a system status check failure occurs. For more information, see [Recover your instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html). 1. Start your SAP HANA database and perform your validation. **Note** If necessary, complete any SAP HANA-specific post-migration activities. 1. Check the connectivity between your SAP application servers and the new SAP HANA instance. 1. If necessary, complete any AWS-specific post-migration activities, such as setting up Amazon CloudWatch, AWS Config, and AWS CloudTrail. 1. Complete post-migration tasks to ensure that you are not charged. + Review and confirm if you need to cancel reservations once migration is complete. + Review and confirm if you need to release Amazon EC2 Dedicated Hosts through the console. Once a reservation is cancelled, on-demand charging begins for the dedicated hosts until they are released from the console. # Security In the AWS Cloud Adoption Framework (CAF), security is a perspective that focuses on subjects such as account governance, account ownership, control frameworks, change and access management, and other security best practices. We recommend that you become familiar with these security processes when planning any type of migration. In some cases, you might need to get sign-off from your internal IT audit and security teams before you start your migration project or during migration. See the [CAF security whitepaper](https://d1.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf) for a deeper dive into each of these topic areas. Additionally, there are AWS services that help you secure your systems in AWS. For example, [AWS CloudTrail](https://aws.amazon.com/cloudtrail/), [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/), and [AWS Config](https://aws.amazon.com/config/) can help you secure your AWS environment. See the following AWS blog posts for help analyzing and evaluating architectures and design patterns for the VPC setup and configuration of your SAP landscape. + [VPC Subnet Zoning Patterns for SAP on AWS](https://aws.amazon.com/blogs/awsforsap/vpc-subnet-zoning-patterns-for-sap-on-aws/) + [VPC Subnet Zoning Patterns for SAP on AWS](https://aws.amazon.com/blogs/awsforsap/vpc-subnet-zoning-patterns-for-sap-on-aws-part-2-network-zoning/) + [VPC Subnet Zoning Patterns for SAP on AWS](https://aws.amazon.com/blogs/awsforsap/vpc-subnet-zoning-patterns-for-sap-on-aws-part-3-internal-and-external-access/) Beyond VPC and network security, SAP HANA systems require routine maintenance to remain secure, reliable, and available; see the [SAP HANA operations overview](https://d1.awsstatic.com/enterprise-marketing/SAP/SAP_HANA_on_AWS_Implementation_and_Operations_Guide.pdf) for specific recommendations in this topic area.