Run SAP HANA Migrations Like a Factory

[petr_solberg]

We started the HANA journey in 2011 implementing a new BW system on HANA.

By 2014 we were planning to migrate other BW systems from companies within the group
to HANA.

At that time there was no option for the TDI (Tailored DataCenter Integration) model, so it was the Appliance Model, something which was new though was the SAP HANA DMO (Database Migration Option) migration process.

As the overview from SAP says,
(DMO) that combines upgrade and database migration in one step.

One process, one tool, one downtime. Migration

Being a large organisation, with multiple operating companies, there were a number of production BW systems which were in the plan to be migrated to SAP HANA. The long term goal being consolidation and reduction of duplication, the shorter and medium term plan being platform harmonisation as preparation for the consolidation.

Looking at the number of productive BW systems we had, and consequently the number of non-Prod BW systems, we knew we were going to be doing a lot of SAP HANA migrations. On top of that, since the future of most of the on-premise Business Suite is to have HANA database, we also knew there are a lot of non-BW HANA migrations waiting for us.

The sheer quantity of HANA migrations ahead of us lead us to putting attention onto how we were going to execute HANA migrations, and looking for a way to make HANA migrations run like a factory and with the self-confidence that we have when executing Support Packs or Enhancement Packs.

We wanted to make the HANA migrations less of a frightening one off task that we need to get through, and more into a routine task that we can repeat again and again and with different resources.

This meant we needed to take the HANA migration process apart, and break it into pieces, and fully understand each piece, and document and procedurise each piece so that it can be repeated again and again.

The good thing with the DMO Procedure is, it is comprised of a number of stages, each can be documented and prepared and evolved with eacvh migration, the phases are:

Prepare
Upgrade
Switch DB
Migrate App Data
Finalise
Start SAP on HANA

I am sure like most people reading this blog, we've all done a lot of Support Pack Upgrades and Enhancement Pack Upgrades and we all do these upgrades routinely probably on a yearly basis and with a well documented approach which the respective Teams are very familiar with, including upgrade preparation, execution, CutOvers, testing etc.

Our goal from the beginning, was to get to the same point with the HANA migrations using the DMO process.

The first BW landscape to have a DMO migration project involved a lot of preparation, we ran Proof of Concept DMO migrations, we ran test migrations in D, Q, P, and on top of that we did a (test) Production Migration Dress Rehearsal where the test migration was executed as if it was the real thing, with everybody involved taking their roles, tracking execution times for every item against the clock evening though we were working 9 to 5, and fully understanding dependencies between all tasks in the plan.

From the very first PoC DMO migration we began building the "CutOver" plan (including recording task duration times), using Excel we listed, line by line, any task deemed significant enough to require a line item. With every migration (test or formal), the "CutOver" plan evolved and grew, the CutOver plan was used as a tool not only to record large milestone items, but also as a tool to track and ensure the little details are completed and ticked off. CutOver plans were created for D, Q, and P, every migration was an opportunity for continuous improvement and to learn from the previous and refine and evolve the process.

Another tool which we developed was to use Excel to create a 14 Days Forward Looking Plan for all systems involved in the Project. so imagine you have your systems D, Q, P on the Y Axis, and the days on the X Axis, this is a continuously live Excel sheet where you are continuously writing the forward looking activities for the next 14 days across all systems, and where tasks are delayed they are pushed back and where tasks run faster than expected they are moved forward. This 14 Days Forward Looking Plan enables everybody who has any requirement or interest to know exactly what is happening today, tomorrow, next week to be able to see at a glance exactly where we are and what we are working on. The 14 Days Forward Looking Plan includes everything the Basis Team is working on, phases of DMO, testing, whatever the task may be.

Ultimately, writing this level of documentation and tracking, we were moving towards our goal of preparing a foundation standard where documentation can be shared, new reources can join the Team and ramp up and become productive quickly, and follow the previously proven approach and evolve it further.

This weekend just gone, Easter 2017, we went live with another Production HANA DMO Cutover, following the same approach, continuously evolving the documentation and refining the process and plans.

Looking back, for the first DMO landscape migration the project timeline was 9 months, during that time we performed a PoC DMO migration, test migrations in D, Q, P, a Dress Rehearsal for Production and then the final D, Q, P migrations, 8 DMO migrations in total.

The second BW landscape to have a DMO migration project, took the documentation, approach, procedures and learnings and experience from the first, and evolved and refined them further with every lesson learned. From the beginning of the second BW landscape DMO migration we had a goal to get the Project timeline down from 9 months to 5 months, and with only a Sandbox test migration and then straight into the final D, Q, P migrations, the goal being to behave with HANA DMO migrations like we behave with Support Pack Upgrades and Enhancement Pack upgrades. The plan worked, the Project was a success, there were more lessons learned and the procedures, CutOver Plans, 14 Days Forward Looking Plans, and procedures evolved further.

Then came the third BW landscape to run through the DMO process, again we took the existing approach (with the goal to evolve it further) and had the goal to reduce the timeline further to 3 months, to tell the truth we failed, we did it in 4 months, from Sandbox DMO migration to final D, Q, P, four DMO migrations in total to bring a BW landscape to HANA using the DMO.

I can say, we have achieved our goal, after 16 DMO migrations, we are running SAP HANA Migrations like a factory and with the level of self confidence that we run Support Pack Upgrades. We have well documented procedures which are continuously evolving, and by having the 14Days Forward Looking Plans from the previous migrations at any time we can always compare to how things worked out in the past, and with the previous CutOver plans and timings we can compare previous timings to ensure that the latest activities are in line with previous. For example we know how long every task should take, we know how fast (from the experience of previous migrations) the data should load into the HANA db, we know what tuning was performed last time and the effect it had.

So why this blog ?

I want to share this experience with others, maybe you have a better approach and we can learn from you, maybe your vision is something like ours.

For all of us in the SAP world, HANA is not going away, and as time goes on we will all be running more and more of our SAP systems on HANA, and unless we're doing new installations this will mean a lot of HANA migrations. We shouldn't fear the HANA migrations, we should look at them as a necessity to begin the next part of our SAP journeys, and find ways to make these repetitive migrations as successful, fluid, efficient and repeatable as possible.

What next ? Let's open this discussion, if you've got useful lessons from your approach to delivering bulk HANA migrations share them here for the benefit of all.

All the best,

Andy.