We just completed a migration to HANA for one of our customers, and I'd like to share some of the key learnings we acquired throughout that experience.
Our customer in this project is one of the biggest German vehicle manufacturers , and this particular system is an essential and critical component in the Sales digital backbone across more than 10 different key markets across the world, being used by over 4500 users.
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.
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?
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.)
Now we look forward to exploit the benefit of the technology to offer solutions that were not feasible with the Oracle based system. I hope to write soon about them.
Our customer in this project is one of the biggest German vehicle manufacturers , and this particular system is an essential and critical component in the Sales digital backbone across more than 10 different key markets across the world, being used by over 4500 users.
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.
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:
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?
- 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
- 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.
- 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.
- 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.)
- Iterate the process in your environments, to accumulate experience and to refine and improve the migration process.
- 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.)
Now we look forward to exploit the benefit of the technology to offer solutions that were not feasible with the Oracle based system. I hope to write soon about them.
- SAP Managed Tags:
