Melchior Du Boullay

Considerations Before Migrating To SAP HANA

Blog Post created by Melchior Du Boullay on Sep 9, 2015

HANA has been the hottest new technology from SAP in recent years. The innovative in-memory database, that is supposed to significantly accelerate the speed of applications, improve business processes, and positively affect the user experience, has been gaining significant interest from customers.

sap-hana.png

oXya, a Hitachi Data Systems company that provides enterprises with managed services for SAP, has significant experience with HANA migrations. To date, we have migrated to HANA about 30 of our 220 customers, or more than 10% of our customers. This is a much higher percentage than SAP’s official, overall HANA statistics, which stands at under 3% of SAP customers who have migrated to HANA. The number of SAP landscapes we have migrated is several times higher and well over 100, as we’ve migrated multiple landscapes for each customer.

 

oXya was one of the first companies in the world to perform HANA migrations. This blog’s goal is to help you, the SAP customer considering a migration to HANA, based on our extensive experience with SAP HANA. What are the main considerations you should look at, when considering a HANA migration? What may be some considerations against such a migration?

 

 

Cost: HANA is expensive

 

First discussion around any HANA migration is usually around cost, and especially the license cost. This is where you should ask yourself – am I ready to make this investment?

 

HANA is expensive. Of course, the discussion should be about HANA benefits and whether the migration is worth the ROI, but many customers don’t get to that stage; the investment itself is a barrier tall enough to prevent a migration, or delay the decision to some point in the future.

 

So what costs are involved with a migration to HANA?

 

1. HANA database cost. If you are currently running your SAP environment on an Oracle database (or MS-SQL, DB2 or any other), then you’re only paying annual fees for that database; the cost of purchasing the database itself had occurred in the past.

 

Migrating to HANA means you need to purchase an entirely new database, HANA. The initial database cost (Capex cost) will be at least a six-digit number in US dollars, and can easily go to a seven-digit number, depending on what you do at your SAP environment, which affects the size of the HANA appliance. We’ll get back to sizing later on, as that’s a critical point with HANA.

 

2. HANA annual maintenance fees. As a ballpark, your annual HANA license fees will be around 15% of what you’re paying to SAP for your other SAP licenses. So, for example, if you’re paying SAP one million dollars annually in maintenance fees, then you’ll pay around another 150,000 dollars every year, in HANA maintenance fees.

 

3. Cost of infrastructure for HANA. The prevalent method for installing HANA is on a dedicated appliance; the cost of that appliance depends on the size you purchase. HANA can also be installed as a Tailored Database Integration (TDI), where HANA is installed on larger, existing servers (compute, storage) in your datacenter, rather than as a separate appliance. In both cases, HANA requires significant hardware resources to run efficiently. The actual cost of hardware depends on the size of the HANA license.

 

4. HANA sizing. With HANA, you’re paying per gigabyte on the HANA appliance. This cost per GB applies to both the HANA license itself, and also to the hardware appliance. For example, if you’re running ECC on a 1TB appliance, then you will need to purchase a HANA license for a 1TB appliance. This means that the size of your SAP landscape and how your company use SAP on a daily basis have direct influence on your HANA cost.

 

Since you’ll be paying HANA fees per size, the correct sizing of your HANA appliance is very important. You don’t want to buy a HANA appliance that is too big, and pay for extra that you don’t use; you also don’t want to buy a HANA appliance that is too small, insufficient for your needs. Many companies are contracting oXya to perform the correct sizing for them, as correct sizing has a major effect on their cost, both appliance size and HANA license.

 

5. HANA Migration. One additional cost to consider is the cost of the migration project itself. Your in-house SAP team does not typically have experience to perform such migration projects. You need to hire the services of an expert company such as oXya, who has done many HANA migrations and has the knowledge, experience and best practices to perform the migration project for you.

 

 

HANA benefits: it’s not just about speed

 

HANA is not just about speed, and that’s important to understand. HANA is also about new functionality. There are many SAP functional consulting firms, who would help you in this area (oXya is not an SAP functional consulting firm). You should consider if you want to leverage that new functionality. If yes, then the new functionality is certainly a great reason to move to HANA.

 

However, if you’re only interested in increased speed for your current SAP applications, then HANA may not necessarily deliver on your expectations. While some people have attributed a 20x factor to HANA, with regards to increased speed, the truth is that you probably won’t get that. The speed of any process you have, like ERP or HR, can’t really go 20x faster for most of the major processes.

 

Don’t get me wrong – customer processes do run faster after a migration to HANA. In one representative case, for example, there was an improvement in the run time of a process from 15 hours to 8 hours. This is a great improvement, nearly 2x, yet the customer was disappointed. They expected much more from HANA. They thought the process will run in under an hour, meaning 10x faster, and that didn’t happen.denver_140821_0272_lo.jpg

So what is the challenge about processes and speed?

 

HANA is designed to run standard SAP processes, meaning processes that have been implemented and are running exactly like SAP designed them. In such a case, a given process can run significantly faster, even x10. This is one of the reasons why SAP keeps telling its customers to “go back to standard”; SAP wants customers to use the standard processes, those that SAP designed, so customers gain the maximum benefits from HANA.

 

However, the real world is quite different. Most SAP customers today have customized their SAP applications, with the help of functional consulting firms. I’d estimate that at least 90 percent of customers have modified the processes that SAP developed, in order to make the process better aligned with their specific business needs. However, these modifications affect the possible speed improvement with HANA, because these modified processes are not optimized for HANA. The result for most customers, from our experience, is that a migration to HANA brings improvements of “only” 1.5x to 2x in speed, and customers feel disappointed with that performance improvement.

 

The bottom line: if you’re planning a HANA migration just for the sake of performance, meaning making SAP faster, then that may not be a good enough reason for such migration. You’ll be paying a lot, and depending on the specific process—you may not get much improvement in speed, and certainly not what you’re hoping to get. I would therefore suggest that you plan your HANA migration carefully, taking into account additional benefits—and you won’t regret migrating to HANA!

 

 

POC is the way to go

 

Most of our customers are asking us to do a Proof of Concept (POC) for HANA, to see what such a migration will give them. We support this approach and encourage you to take the POC route, have a real test and see if the new functionality and improved speed meet your expectations.

 

POC has to be done with your real, live data, in order to know if the migration to HANA will meet your demands. Using your real, live data in a POC is a basic requirement, because that’s the only way you’ll know how your customization of SAP will be affected by the HANA migration. Using demo data from SAP is irrelevant, as it will not show you how the HANA migration will impact your specific SAP environment, especially in cases where functional customization was performed.

 

oXya is performing multiple POCs for multiple customers and prospects at any given moment. If you’d like more details, just contact us and we’ll discuss your specific requirements.

 

 

Considerations for delaying a migration to HANA

 

There are three main considerations that prevent customers from migrating to HANA. Furthermore, our experience shows that for most customers, a migration to HANA is not a definite “Yes” or “No” decision, but more a question of timing – when exactly to perform the migration, based on the following:

 

1. HANA cost and infrastructure refresh cycles: when I wrote about HANA costs at the beginning of this blog, I wrote mostly about the HANA license costs. Here, I’m referring specifically to the cost of hardware, and to refresh cycles for SAP infrastructure (servers and storage). A refresh cycle takes place every 3-4 years; customers depreciate their equipment over 3 years, but will often wait another (4th) year before buying new equipment.

 

Hence, a customer who has just ‘recently’ purchased new infrastructure (and ‘recently’ can be 1-2 years ago), and already spent a significant budget on that new SAP infrastructure, would usually not migrate to HANA at present time. They simply don’t have what to do with the existing (relatively new) infrastructure, and they won’t invest significant amounts in new infrastructure for SAP.

 

The exact same argument works the other way around. When a customer’s refresh cycle is coming up and the budget for new infrastructure is approved, that would be a good reason to move to HANA. The cost of moving to HANA may be a bit higher, compared to a regular, non-HANA infrastructure refresh, but that difference is easier to justify, due to the major infrastructure refresh.

 

2. Concerns regarding HANA maturity and migration path: we’re speaking with a huge and well-known retail brand about HANA, and they listed three concerns regarding this migration. The first concern was the already-mentioned cost; they told us the migration to HANA was too expensive for them. In addition to cost, their second concern was that HANA was not yet mature enough. They didn’t trust it for running the Business Suite on HANA, and for them to base their entire business on HANA.

 

Personally, I believe that HANA as a solution is mature, and for itself brings no risk to the organization. However, for that specific customer, there was another, third concern, which was a very complex, long and costly migration path to HANA. We analyzed the migration project and came to the conclusion that it would take about 18 months, from start to finish, since this customer has a very complex SAP environment, with many things that need to be taken into consideration. The bottom line is that this customer is right in not migrating to HANA at present, due to the complexity of the project, but this is not related to HANA maturity.

 

3. Issues with Product Availability Matrix. A third common reason, that prevents customers from migrating to HANA, has to do with product availability matrix. Some applications just can’t be migrated to HANA, and when such an application is mission-critical for a customer, that can prevent the entire migration project.

 

We have a customer that delays the migration to HANA, due to an application that is critical to their operations. That application is not from SAP, but it’s connected to the SAP system. The application’s version is not compatible with HANA, so HANA will not be able to read this application’s database. The customer also can’t upgrade the application, because that project is also very long and complex. The customer is planning to replace this application with another software package in about a year, to support a future migration to HANA.

 

The above example is relevant to many customers who have external, 3rd party products that are connected to SAP with interfaces. When these external products are critical to the business, yet can’t work with HANA, then such a scenario puts the entire HANA migration on hold. Before migrating to HANA, we must verify that all these products have a clear migration path to HANA, and they will continue to work with HANA.

 

 

Conclusions

 

As you read in this blog, a migration to HANA involves many considerations that need to be carefully analyzed and discussed. oXya, with about 600 SAP experts serving more than 220 enterprise customers worldwide, is having such discussions with customers on a daily basis.

 

If your organization is considering a HANA migration, feel free to reach out to us for consultation. You can ask questions or post comments here (I promise to answer), or contact your HDS rep about this.

 

 

 

About the author: Melchior du Boullay is VP of Business Development and Americas Geo Manager at oXya, a Hitachi Data Systems company. oXya is a technical SAP consulting company, providing ongoing managed services (run management) for enterprises around the world. In addition, oXya helps customers running SAP with various projects, including upgrades and migrations, including to SAP HANA. Enterprises migrating to HANA are using oXya to perform the HANA migration for them, since they usually don’t have the in-house skillset and prior knowledge to perform that migration.

Outcomes