As the end of support for SAP ECC looms, the option of migrating to SAP…
Migrating from one operating system or database to another can be a challenging process. Many factors come into play, ranging from business requirements to strategy, IT department skillsets, data formatting issues and so forth. Migrating to SAP HANA, in particular, can be a heavy lift. This article offers some insights and suggested SAP HANA data migration steps.
What is SAP HANA migration?
SAP HANA migration is the process of switching from whatever database you’re using with SAP today to SAP HANA. After the migration, SAP HANA will be your main database supporting your SAP landscape going forward. One factor making SAP HANA migration challenging relates to how HANA organizes the data itself. SAP HANA is built as a columnar database. In contrast, traditional RDBMS systems are row-based. SAP HANA is also an in-memory database, meaning it stores data in solid state memory (RAM) for improved performance. This difference can complicate the migration.
SAP ECC migration to HANA – step by step process
Working with many clients who run their businesses on SAP, we have devised an effective, step-by-step process for migrating SAP ECC to SAP HANA. The specifics of each migration vary based on unique aspects of each client’s SAP landscape and business. However, in general, the following steps have been proven to work well:
1. Sizing the SAP HANA landscape – It’s important to scope your infrastructure carefully for SAP HANA. The platform’s distinct data structure makes it faster than its competitors. Its speed shows up with complex, analytic queries in particular. This is where a columnar database lets you to load only the relevant data columns. A columnar database does change your resource requirements at the same time. A traditional database supplements its data with search indices, which speeds up search at the expense of a larger data footprint. In contrast, SAP HANA shrinks the data footprint, but requires relatively high CPU and memory resources.
Given these constraints, you don’t want to under- or over-provision database capacity. The best practice is to determine the amount of memory your main data set will require and plan from there. You will want to establish the memory size for static and dynamic data as well as the disk size requirements for “persistence storage.” These metrics should align with the CPU you provision to handle the database workloads. The SAP Quick Sizer tool and sizing reports can help.
2. Remediating custom code – Custom code complicates the SAP HANA migration process. Older systems tend to have custom code as well as outdated data modeling processes. These are poorly suited to SAP HANA. You have to remediate these issues before you migrate.
3. Selecting a platform – Do you want to run SAP HANA on-premises or in the cloud? How about a private cloud? We can help you work through this decision. There are also certified SAP HANA appliances available. This pre-configured approach can save time and ease you into strong database performance.
4. Determining a migration strategy – You have choices in the way you do the actual migration. You can do the standard system copy approach using tools like SWPM, R3load and Migration Monitor. Alternatively, you can use the Database Migration Option (DMO) in SAP Software Update Manager (SUM). This mode of migration combines system update and a technical migration.
5. Cleansing the data – A database migration provides a great pretext for doing a data cleanse. You can de-dupe and standardize data based on master data sets. You can conform fields to new standard schemas for data types like nine-digit zip codes and so forth. Cleansing creates benefits like a reduced data foot print that cuts your infrastructure costs.
6. Doing a proof of concept – It’s a good idea to test your migration in a Proof of Concept (PoC) before you pull the trigger on the full migration. A PoC enables you to validate the migration process. You can perform a POC in your Sandbox environment, identifying issues that might negatively affect the ultimate migration.
S/4HANA data migration, migration tools, prerequisites, etc.
Migrating data to S/4HANA presents similar challenges to the SAP HANA data migration. One difference, though, is that your system must be in Unicode. If you are running Unicode in your SAP landscape, you need to convert to Unicode before doing an S/4HANA data migration. From there, it’s a comparable process. You do your Pre-Checks on the SAP Business Suite at the start. You do Maintenance Planning. Once the Maintenance Planner results show that you have “passed,” and you have created a new stack.xml file, you can move to the Realize Phase. This is executed in the SUM.
SAP HANA data migration requires the right partner
SAP HANA isn’t a one-size-fits all solution. Its data migration is a complex, technical process. Migration usually works well with a partner who possesses deep expertise and familiarity with the HANA platform as well as its operating system, hosting environment and migration methodology. Without these competencies, the partner won’t be able to utilize SAP HANA benefits like high performance, real time capabilities, security and business value. Indeed, the wrong partner may not even be able to complete the migration project at all.
It takes strategic planning to succeed with a challenging SAP HANA data migration. Migration can be relatively painless, or deeply disruptive depending on how well you plan. Your partner should work closely with you to control costs and keep disruption to a minimum. For example, an SAP Suite on HANA system may benefit from having older data archived before migration begins. This ensures a speedy process, optimal performance and a smaller (and more affordable) footprint.