(/)

SEARCH
()

Bluefin (/) › John Appleby (/blogs/john-appleby) › Tips for a successful SAP Business Suite on HANA migration

Tips for a successful SAP Business Suite on HANA

migration
John Appleby (/Blogs/John-Appleby/), US General Manager,

Published in 5 Categories - Wednesday 22 June 2016

Related SAP Suite on HANA vs SAP S/4HANA – the differences explained (/Blogs/Mark-Chalfen/April-2016/SAP-Suite-on-HANA-vs-
SAP-S4HANA-the-differences)
The SAP® Business Suite 4 SAP HANA® (SAP S/4HANA) FAQ (/Blogs/John-Appleby/February-2015/The-SAP-Business-
Suite-4-SAP-HANA-(SAP-S4-HANA))

Larger organisations are breaking their journey to SAP S/4HANA into several steps to reduce risk. The first
logical large step is the upgrade of the core ERP system onto the SAP HANA database platform. I reached
out to my team to answer the question: How do we ensure the success of an SAP Business Suite on HANA
migration? Here's what I found out.

1. Start with a full-size production copy

It can be tempting to start with your first system as a development system, but this is a mistake.
You need to cut your teeth on a real full-size copy as soon as possible, because it's only here
that you will see what it's like to work on a real system.

A production copy will have the full database size, and so you have the beginnings of the timings
for a cutover plan, you can build a detailed run book based on a simulation of production, and
you have the current code set (development systems often have a different code-base to
production).

2. Start housekeeping early

When you have an in-memory database like HANA, you don't want to be wasteful with database space, so it's useful to start a spring clean and
delete all the data you don't need before you get to HANA. We have a standardized process for this and it typically cleans up hundreds of
gigabytes, even terabytes, of database. In one client, we found a housekeeping table that was 1.2TB in size.

Because of the amount of data that needs deleting, we often find that housekeeping often takes 2-6 months to complete. The clean-up jobs
can take a really long time to run, and you don't want to impact business operations, by needing to be too aggressive.

3. Burn in your production hardware

When you cutover to your new HANA database on Sunday at 4am, you want to know that it will be reliable. We always recommend the
production hardware is installed early, configured as an High Availability (HA) cluster, and then used for 1-2 mock migrations.

If it's ready in time, you could even use it for your first sandbox (see point 1). Either way, you want it running for some time prior to cutover, so
any teething hardware configuration errors are resolved prior to production migration.

4. Consider rolling in other infrastructure changes

The primary cost driver of a HANA migration is the number of test cycles. You should consider rolling in additional changes so you can improve
stability and reduce TCO because you will be testing so thoroughly.

In the past we have rolled in all manner of changes including Linux Application Servers, VMWare, Unicode Conversion, Enhancement Pack
upgrades, etc.

5. Look at the entire application landscape

Your Business Suite system is at the core of your SAP environment and will touch almost everyone in the application support area of your
organization. This means there is an opportunity to update other areas at the same time, like BW, Portals, or Solution Manager.

You will have a project management office, Basis, ABAP and Test Management resources already available, and extending the scope is
incremental compared to doing a separate update at a later time.

6. Focus on Test Management

Many clients have mature SAP R/3 environments, which have been in place for 10-15 years or more. When they were implemented they had a
solid test management process but over a period of time, the quality and structure of test management has degraded.

The SAP Business Suite on HANA is the first step for organizations to get to S/4HANA, and there will be more testing in the years to come, so
it really makes sense to do a good job of test management now. Evaluate your test coverage as compared to business process, ensure you
have modern tools in place and look at test automation where appropriate.

7. Use the right tools for custom code remediation

Rather like test management, custom code has ballooned within SAP environments over the last decade. We often see clients with 30-50,000
custom code objects, and 30-80% of this code isn't even used. Reports were written for the 2009 year end close and never run since.

It is critical to do custom code remediation on HANA, because SAP spent a lot of time optimizing the Business Suite on HANA, and your
custom code will not be optimized by default. This can lead to severe performance problems, and issues with functionality.

SAP Solution Manager is the starting point for this, with tools like Custom Code Cockpit (CDMC), Usage & Procedure Logging (UPL) and
Clonefinder, which help you understand your custom code. We also partner with tools like smartShift, which takes the custom code from your
existing system and applies a set of algorithms to automatically remediate your custom code - reducing the cost, and human error.

8. Identify and benchmark critical processes

You mention the words HANA, and your business users will expect lightning speed. The expectations of a Business Suite on HANA project will
be high, and there will be a lot of excitement!

It's important to identify those processes that are important to the business, and benchmark them. This might be some critical month end
reports, but in one client’s case it was an approval mobile app for promotions - an app used by C-suite executives.

Once you have benchmarked them today, you can ensure they are measured as part of the test process, and additional focus can be put on
ensuring they are optimized for the HANA platform. This will help with the communication strategy.

9. Get the right project assets in place early

There are a few project assets which are specifically important to a Business Suite on HANA migration. We recommend that you get this in
place in the project library, available to all in a shared location, and update them regularly.

a. The first is the Run Book, which is a step-by-step guide to the migration and typically spans a few hundred pages. It means that if you need
to switch out resources at the last minute, due to unforeseen factors, you can bring in a very experienced resource to look after the next step
of the project. In addition to this it ensures that at 5am on a Saturday morning at the end of a long shift, mistakes are less likely to be made.

b. The second is a set of project plans. We recommend 3 levels: High-Level, Mid-Level and Detailed.

High-level plan: used to communicate with the steering group, and it has the milestones defined on it, so a C-suite stakeholder can see
where the project is at a weekly granularity in PowerPoint.
Mid-Level plan: typically printed onto a large sheet of paper and is human-readable, so all project members can understand progress;
it's usually planned at a day-by-day level in Excel. 
Detailed project plan: is in Microsoft Project, and often several thousand lines long, and updated by the Project Management Office.

10. Add an extended hypercare optimization phase

We have found that despite taking care with custom code optimization, good planning, and test management, a few performance issues will
fall between the cracks and some processes may be slower on HANA, because they were optimized for a disk-based RDBMS. In addition,
because HANA is so much faster than your old database, some processes will need to be reshuffled in the production system, so you can
reduce batch Windows.

For both of these reasons, we recommend you run an extended hypercare. A go-live window is typically 1-2 weeks after month end, and we
recommend you run it for 6-8 weeks after that, rather than the usual 2-week window. This enables you to immediately take advantage of the
HANA platform improvements and use the existing project team to capitalize on the benefits early.

11. Remember it is a technical migration

 In most cases, the Business Suite on HANA migration is a purely technical exercise. It's not like S/4HANA where there will be process changes,
a new UX (Fiori) etc. You can get onto the Business Suite on HANA and after that focus on the cool things like the Fiori UX, HANA Live etc.

What this means is that you can afford to be aggressive with your timeline. You still need to do a great job of planning, testing and executing,
but it is possible to move quickly, and be risk-averse. For example, we have moved a large SAP BW client to HANA in the manufacturing
industry in 8 weeks, and a large SAP ECC client to HANA in 16 weeks, including a large amount of code remediation and thousands of test
cases.

12. Consider following the sun

We have a cohesive, global Basis team across three time zones that operate as a single unit. They know how each other works, and they have a
shared approach and document storage. This has some cost advantages, but more than anything else, it accelerates the migration phases of
the projects. In addition, it means that even the first migrations are run 24/7, which gives much more accurate early timings.

Final Words
Thanks to Lloyd, Brenton, Srinivas and Anna for their input into this blog. It's been a reminder to me that with a project like this, the team is
greater than the sum of its parts: each person had a unique and relevant perspective to this story.

As always, I'd love to hear your experiences. Happy HANAing!

(/blogs/mark-chalfen/april-2016/sap-suite-on-hana-vs-sap- (/blogs/james-appleby/february-2015/s-4-hana-after-23-years-
INSIGHT INSIGHT
s4hana-the-differences) of-r-3,-welcome-sap-r-4)

SAP Suite on HANA vs SAP S/4HANA – the differences S/4 HANA: After 23 Years of R/3, welcome SAP R/4
explained 10 Feb 2015
22 Apr 2016 James Appleby
Group Chief Executive
Mark Chalfen
SAP S/4HANA Global Lead

Insight (/Insights/cat_Insight)

SAP ERP (/Insights/cat_SAPERP)

Published in:
SAP HANA (/Insights/cat_SAPHANA)

SAP ECC (/Insights/cat_SAPECC) SAP S/4HANA (/Insights/cat_SAPS4HANA)

Read more from John

Tips for a successful SAP Business Suite on HANA migration (/blogs/john-appleby/june-2016/tips-for-a-successful-sap-business-suite-on-

hana-m)

The SAP HANA Vora FAQ (/blogs/john-appleby/september-2015/the-sap-hana-vora-faq)

Bluefin at SAPPHIRENOW 2015 (/blogs/john-appleby/may-2015/bluefin-at-sapphirenow-2015)

View John's Profile ( /Blogs/John-Appleby/)

Want to know more? Subscribe today ›

Sign up to our newsletters and receive leading industry insights from Bluefin.