Saturday 10 December 2016

EHP upgrade and HANA migration. Lessons learnt

The system was based on SAP EHP Release 7.01 running on an Oracle database that had over 8.7 Terabytes. Additionally, the pre-existing landscape and the target one are hosted on premises, under virtual servers on vSphere 6.0. Software  wise, our customer system is based on Vehicle Management System (IS-A-VMS), although with a significant amount of customizations and custom code.

The original motivation to initiate this project followed an analysis of the usage of the system, and based on our predictions of additional data volume, additional markets, etc. it was quite clear that we needed to take some measures to keep the response times within reasonable limits. Furthermore, it was quite obvious that HANA was the future for SAP based systems, so at some point we would have had to contemplate a migration.

So that was our challenge: To re architect the solution landscape, prove that the solution would work with HANA (only with minor modifications) and to design a safe, reliable and very fast  migration process, without affecting the ongoing rollouts, releases, etc. of the system.

At a very early stage we decided to divide the project in two distinctive phases:

1. Proof of concept: The idea being to migrate as soon as possible an existing development instance to HANA, in order to do an initial evaluation of the process and the changes required to the custom code. In order to speed up the process, we decided to use the HANA Enterprise Cloud to host that test environment.

2. Iterative migration of the environments,  refining the process, and incorporating lessons learnt into the next environment migration.

EHP upgrade and HANA migration. Lessons learnt

We completed the migration of the production system (that was the last one in our migration plan) in November, and we are incredibly pleased with the results, but also about the process we followed, that ensured minimum disruption. These are some of the results, in terms of performance:

EHP upgrade and HANA migration. Lessons learnt

Background process benefit even more, in terms of performance, but the foreground ones are the ones that our user community noticed specially. The only drawback is that they had to cut their coffee breaks short!

An integral part of this migration project has been the planning in advance of a data lifecycle management subproject to archive and clean up the system before the migration of as much data as possible. After iterating on each environment, and performing the migration, the data storage requirements has been reduced between 60%  to 70%.

What recommendations can we give to anyone thinking of embarking on a similar project?
  1. Take a good look at the current architecture of your solution and identify how HANA will integrate in it. Be as thorough as possible to identify required changes and adaptations
  2. Involve the application software engineers, in addition to your technical infrastructure team. Application modifications need to be incorporated in the migration, even if it is only for compatibility reasons.
  3. A proof of concept is a very good way to find how your application will perform in a migrated environment, and will give the opportunity to identify in which areas you need to focus.
  4. Detailed planning is a great tool to enable and coordinate with all the participants and to have a reference of the activities and timelines, specially if you need to align a migration with ongoing projects of software lifecycle activities (releases, deployments, etc.)
  5. Iterate the process in your environments, to accumulate experience and to refine and improve the migration process.
  6. Be ready for small unexpected issues to happen in a long running migration process. Therefore, it is always beneficial to gather experience in pre-production environments to minimise the number of unexpected problems.
After this experience, we strongly recommend that you start planning migration to HANA, if you still haven’t done it.  There are enough options to accommodate a migration process, regardless of the constraints you might have (downtime, availability, etc.)

No comments:

Post a Comment