Skip to Content

.

Introduction:

I am not the world expert on this subject, and there are many many people out there who know a lot more, I am learning as I go.

What I am noticing is, in this task there is an opportunity to develop a methodical template approach which can be applied over and over and refined into a smooth approach for delivering BW Hana migrations.

My goal is to document this, for my own benefit and to put my thoughts in a logical format and then refine this and expand the resulting work, and at the same time share with others for the benefit of all.

Having said that, here we go 🙂

I am currently Basis Architecting the migration of two on-premise SAP BW landscapes to SAP BW On Hana and both SAP BW landscapes are unique in as much as they have different:

  . User Groups

  . Appetites for Risk

  . Requirements for Testing

  . Requirements for duration of FREEZE period

  . Requirements for migration downtime duration

There are several options available for migrating SAP BW to SAP BW On Hana, and the choice of which strategy to use is really determined by the above list of drivers.

I will be having more BW landscapes to migrate to SAP BW On Hana in the coming years and therefore, my goal is to use this series of blogs to try to document a template methodical and logical staged approach which SAP Basis Architects who have been given the migration task can work through and use

for the decision process and implementation.

There are many blogs on SCN about installing SAP on Hana or BW on Hana, and even some skimming the surface of the technical side of migrating to SAP BW On Hana and showing screenshots from SAPInst and the other SAP Tools.

This blog series will not be at the nuts and bolts technical level, this blog series is going to lay down a template decision process and approach for an SAP Basis Architect to start from ‘the plain sheet of A4′ through to ”CutOver of the SAP BW On Hana’ migration Project, including all of the decisions and milestone activities and preparation and ongoing tasks right through to the final CutOver.

Migrating SAP BW to SAP BW On Hana – A Guide for SAP Basis Architects – Part 1 The Workshop

Starting from the “two sheets of A4 paper”

For a SAP Basis Architect what is the starting point of a SAP BW to SAP BW On Hana migration Project ?

For me, the starting point is the first time that the SAP Basis Architect hears the rumour about the incoming Business Demand.

What is the first thing to do, what are the first questions to ask, what are the first steps ?

The first questions are:

  . Does the SAP BW On Hana migration project have funding ? If not yet, what are their chances of getting the funding ? Who is supporting it ?

  . When is the project expecting to get the funding signed off ?

The challenge is, if Basis Architecture waits for the funding to be signed off before acting then once the Business Demand gets the secured funding the Demandees will be wanting and expecting to begin immediately.

How to mitigate this, what to do ?

There is a certain element of the chicken and the egg, which came first, the chicken or the egg ? Which came first, the rough project plan or the signed off budget ?

Let’s assume the Business Demand is serious and there is hearsay that the right people have given the funding the nod and it is expected that the funding will be signed off.

What to do now ?

a. Get the ‘ideal world’ timeline from the Demandees

b. Check the highest level pre-requisites are in place for a SAP BW On Hana migration

c. Start planning Basis Resources, identify knowledge gaps and strategies for mitigating knowledge gaps

d. Start talking and getting orientational timelines for delivery of the Hardware

e. From the highest level, plan the SAP BW On Hana Migration Strategy

In Greater Detail:

a. Get the ideal world timeline from the Demandees

Let’s assume that we are currently in Month 1. We need to get the answers to the following questions from the Demandees:

. When is the capex expected to be signed off ?

. What are the Demandees’ goals for the implementation timeline following successful signoff of the funding

b. Check the highest level pre-requisites are in place for a SAP BW On Hana migration

The following questions need to be answered:

. Is the source BW an ABAP standalone or a dual stack ABAP and Java on the same DB ? If Dual Stack, then as a pre-requisite a Dual Stack split project needs to be executed to separate the ABAP and Java stacks

. Is the source BW on a version which can be migrated to Hana or does the source BW need to be upgraded to a version of SAP BW which can be migrated to SAP BW On Hana ? If the source BW version is too low, then an upgrade project will need to be executed to get the source BW onto a version which supports migration to Hana

. Is the Database of the source BW on a version which is supported for migration to Hana ? If the Database version of the source BW is too low, then a DB upgrade project will need to be executed to get the DB upto a version which supports migration to Hana

c. Start planning Basis Resources, identify knowledge gaps and strategies for mitigating knowledge gaps

Are you already a Hana Customer ? Do you already have Basis Technicians experienced with implementing and operating SAP on Hana ?

Will you go for the Hana Appliance Model where the hardware vendor provides a pre-configured solution or do you have the skills inhouse to install Hana using the TDI Tailored DataCenter Integration strategy. TDI is still rare in the market therefore I would assume the answer is no.

The answers to these questions, coupled to your organisation’s appetite for risk will contribute to determining the strategy you select for implementing Hana.

My suggestion would be, if your organisation is new to SAP Hana, or new to migrating BW to BW on Hana, then I would go for the approach of the Hana Aplliance Model and getting the Hana Appliance delivered by the hardware vendor to remove the risk associated with trying to build up competency in installing Hana and setting Hana up at the same time as building compentency in Migrating to Hana and Operating Hana. Get the migration and operation experience first, and plan a strategy within x years for future migrations to start doing your own Hana installations with the TDI approach getting your Team ro have the necessary pre-requisite certifications from SAP.

If your organisation is thin on SAP Hana and Hana Migration skills you are going to need to think about how to mitigate this and ramp up the Hana knowledge in the Basis Team

d. Start talking getting orientational timelines for delivery of the Hardware

Let’s assume your Basis Team will not be installing the SAP Hana Appliance themselves on the Hana hardware, ie you’re planning to go for the Hana Appliance Model and not TDI Tailored Datacenter Integration.

You need to already start talking to your hardware vendor and get orientational answers to the questions:

. If we order a Hana Appliance, what is the lead time and delivery time ?

. From date of order how long before the Hana box will be delivered ?

. How long to rack and stack the Hana box in the data center

. How long for the Unix Team to prepare the Hana Box

. How long to have the Hana Appliance operational

. The RFS for operating the Hana Appliance Model – how will it be structured ?

e. From the highest level, plan the SAP BW On Hana Migration Strategy

This question is difficult at this early stage because there are several main strategies for migrating SAP BW to SAP BW on Hana. The good thing is, later in the is process as a result of following a methodical approach it will become clear which option(S) are best suited to the migration you are working on.

To go into a little more detail,  at this stage it is impossible to choose which BW On Hana Migration strategy to use, because the choice of strategy depends on several factors including:

. Existing versions – is upgrade necessary, eg you meet the Hana pre-req version eg 7.3 but as part of the migration you want to upgrade to 7.4

. Appetite for Risk – Testing – how long will the period for testing be during the migration project

. CutOver Migration Downtime – how much downtime will be allowed during the CutOver, howlong can the Business and the Demandees be without BW ?

. FREEZE period, how long can the FREEZE period be during the migration project ?

The four main migration strategies to BW On Hana are:

. Classic Approach – in place migration

. Frozen System Approach – Loading & Planning stopped

. Downtime Minimised Approach (Loading & Reporting)

. Parallel Implementation

(these all have +’s and -‘s according to the above listed drivers and the decision process for these approaches and their benefits will be discussed in detail in a later blog)

The way to get the answers to these questions is to have a Kick Off WorkShop.

To put it clearly, the first step of the SAP BW to SAP BW On Hana Migration Project, even long before the funding has been signed off, is to get on and have a kick off meeting and already get working on the Project, because, it can take some time to get the funding in place and once the funding is in place the Demandees will be expecting the work to begin as soon as possible.

The Kick Off WorkShop should have the following goals:

. Concensus Consensus Consenesus

. Stakeholders understand Scope of the Project

. Stake Holders understand their responsibilities


. Timeline

. Strategy

. Finding the first highest level answers the above questions (a to e)

Who to have at the Kick Off Workshop ?

Stakeholders:


Basis Team Representation


BW Team Representation

Infrastructure – Unix/Networking Representation

Vendor – SAP

Vendor – Hardware – Hana Appliance Model

To recap, the KickOff Meeting will discuss and achieve of consensus on highest level answers to the following foundation questions:

a. Get the ‘ideal world’ timeline from the Demandees

b. Check the highest level pre-requisites are in place for a SAP BW On Hana migration

c. Start planning Basis Resources, identify knowledge gaps and strategies for mitigating knowledge gaps

d. Start talking and getting orientational timelines for delivery of the Hardware

e. From the highest level, plan the SAP BW On Hana Migration Strategy

Thoughts on Agility in SAP Landscapes

Even if you are not planning to migrate to Hana this year or next, if you are running BW on a Dual Stack installation then one of the best decisions you can take is to Split the Dual Stack as soon as possible. This way, one day, when the Business come back from TechEd, or SAPPHIRE with funding in their pockets and a demand to migrate to BW on Hana asap, your BW landscape will be agile and prepared and ready for the migration without needing a (minimum) 3 months project to execute the Dual Stack Split.

On top of this, still on the subject of agility, if you want to keep your BW landscape agile then as soon as possible upgrade your BW to a version which supports migration to Hana, same again, this way, when the Business come back from TechEd, or SAPPHIRE with funding in their pockets and a demand to migrate to BW on Hana asap, your BW landscape will be on the correct Hana Migration pre-requisite version and you won’t need a (minimum) three months project to upgrade BW.

The BW migration to BW on Hana is a huge subject, and there is so much to discuss on this subject and take into consideration, this blog series has the goal to go through every step logically and sequentially discuss every item and every step of the journey, laying down the foundations for an implementation template approach for migrating BW to Hana.

The next blogs in the series will be as follows:

. Pre-Requisite and Preparation Activities for Basis and BI Teams Preparing To Migrate SAP BW to SAP BW on Hana

. The Possible Approaches For Migrating SAP BW to SAP Bw On Hana

. The Outcome Of The SAP BW Migration To SAP BW On Hana KickOff Workshop And Next Steps

. followed by subsequent blogs for logical steps as we follow the journey

The reason for this sequence is that, in advance of the KickOff Meeting, there are already preparation activities which the Basis and BW Teams can be executing where the results will be contributors to the KickOff Meeting.

Secondly, at the KickOff Meeting, when discussing the drivers for the migration approach, the different possible migration approaches should be discussed and explained so that there is a common understanding amongst all of the stakeholders as to why the approach which is favourite is the best fit for the drivers.

Useful Documentation:

The KickOff Workshop is described in nice detail in the Copa-Hana RDS documentation available at:

http://service.sap.com/rds-hana-copa

Although the RDS is COPA/Hana specific, the section on KickOff Meeting is valid for BW to Hana too

The whole process is described nicely in the following ppt which can be found on google:

HANA2014_A_to_Z_Guide_Part_1 An A-to-Z Guide to Implementing SAP HANA Planning, Scoping, Staffing, Budgeting, and Execution

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Aaron Bennett

    Your Guide is fairly on par with my experience with two very major SAP migrations which involved migrating two legacy SAP instances to another instance for a extremely large Manufacturer of IT Equiptment as well as involvement in anything else that someone hears about one day.  I went through the same Migration with two Major Accounts we supported as Financial Analysts so I benefited from being with different types of teams and seeing how that affected the migration.  To begin this two year process I was given training that was very good but too broad and 5 days of eight hour classes gets mind numbing.  Then we didn’t go thru with the migratoin for a considerable amount of time and what was learned in the class started to fade.  Luckily there was no shortage of Online Training Courses, Documentation on everything from SAP, and the most helpful Subject Matter Experts that knew a great deal about the technical aspects of SAP which is extremely important.  Here is the Catch though and it was voered above…You have to make decisions that will ultimately drive the detail of your reporting and in the organization I was working for you would actually have to redo the whole structure set up during migration because people started caring about topside reporting apparently.  I would say that the biggest challenges I faced during these migrations was First off  Having such a large org with an insane amount of intercompany transactoins that are coming from all types of systems and groups all over the world that may or may not be interested in helping your particular account successfully complete an SAP Migration.  I think the Second Major Challenge that comes to mind is whether or not your team buys into a new system that takes much more time to do your job and is much harder to use than your legacy SAP instances.  This I hope won’t be a problem for most because you shouldn’t migrate to a worse system obviously but I have seen it happen and it is like watching a trainwreck in slow motion.

    A Few Questions I have for the community:

    What is the best way to learn T-Codes I keep getting a a new instance that has different T-Codes and it would be so much easier if I could just get a list and have one that tells me what my roles are and what that actually lets me do.  I used to be able to see my roles but they almost read like nonsense.

    (0) 
    1. Andy Silvey Post author

      Hi Aaron,

      the good thing is on these two migrations, is the Userbase want the migration from SAP BW on Oracle to SAP BW on Hana as they will be getting upgrades at the same time and want to utilise the new functionality.

      Regarding transaction codes, there’s a book (isn’t there always) from SAP Press on just that subject.

      SAP Transaction Codes. Your Quick Reference to Transactions in SAP ERP of Venki Krishnamoorthy, Martin Murra…

      Best regards,

      Andy.

      (0) 
      1. Ajay Uppal

        Hi Andy

        Just wanted to see if you can share some inputs as to how the business outage/downtime can be reduced to bare minimum  while moving BW on Oracle to BW on HANA …looking at around 8TB source system oracle DB ..

        Customer is asking for this final production cutover  to be done in less than 36 hours

        (0) 

Leave a Reply