10 Golden Rules for SAP Suite on HANA & S/4HANA Migrations

[Former Member]

This time last year, I wrote about experiences migrating SAP BW customers in 10 Golden Rules for SAP BW on HANA Migrations. Things change in a revolution around the sun, and over the last year, we have found a sharp increase in the number of customers going live with Suite on HANA. It turns out that whilst there is some transferability of skills from BW to Suite migrations, there are just as many differences.

With that in mind, here's my 10 guidelines for SoH Migrations - they do, of course, apply just as well to S/4HANA!

1) Start with BW on HANA

This isn't an absolute rule and greenfield customers should definitely go directly onto Suite on HANA, but customers with a complex SAP landscape should not go live with Suite as their first system. Why?

I met with Vishal Sikka in TechEd in 2011 and asked him comment that if BW would soon run on HANA, that meant NetWeaver ran on HANA which meant they could easily run the Suite. I asked him why SAP chose not to also announce Suite on HANA support. His comment was that if a large customer's BW system were to go down, they would open a support ticket and get it resolved. If their ECC system went down and they stopped the manufacturing facility, he would get a phone call from a CIO.

Whilst HANA is an incredibly stable database and ECC runs very well on it, HANA will be a new database to the organization and it is best to start with a system which is not transactional in its nature. I always recommend to do BW on HANA first - it allows the training of staff, implementation of infrastructure, backup, high availability and disaster recovery, monitoring processes etc. Once BW is in, the organization will have the maturity to support HANA, and ergo the maturity to migrate Suite.

If getting live on Suite is a priority then you can run parallel projects, going live with BW first, and with Suite 4-8 weeks later.

Some people asked me what they should do if they don't have BW. That's OK, doing BW first is just a neat way to build organizational process intelligence around HANA. If you don't have BW then you just need to be a little more structured around how you build that capability, to mitigate any risk. Things you need to consider include architecture, sizing, networks, updates, backup/restore, HA/DR and monitoring. There's processes like support and incident management, change management, release management and transport management and people-centric items like support personnel and DBAs. Just the same as any other system.

2) Build an Integrated Schedule

This is important for any project, but with Suite on HANA it is essential. There will be connected systems like Supply Chain Management, forecasting systems like BPC, reporting systems like BW, third party interfaces and integration. There will be a raft of front end tools like SAP Gui, Portals, Web Stores. Cloud integration to SuccessFactors or Ariba or Salesforce.

You need to involve teams from Basis, Architecture, Infrastructure, Networking, Custom Development, Test Management, Finance, HCM and others. Suite touches the whole business.

We always build an integrated schedule that describes the project in way that can be displayed on a single monitor screen, so everyone understands what is happening and when. Now ensure that everyone buys into this.

Make sure that your integrated schedule also contains a reference to other releases or projects which will run concurrently, so you can track them, any change freezes, or dependencies. It's important in an integrated schedule that you ask teams not to pad their times, but to provide realistic estimates for how long tasks will take. Then, as a project manager, you add in contingency which will allow some slippage for issue resolution.

3) Build mid-level and detailed plans

I like to have 3 levels of plans for a migration project. The integrated schedule which typically describes the project on a weekly basis is the first.

The second is the detailed plan, which is at a task-time-resource level. Detailed plans are very hard to read, and only experienced project managers really know how to work with them and interpret them, building Gantt charts with complex dependencies, resource costing, WBS and allowing burndown charts and earned value calculations. Typically only the PMO needs to use the detailed plan.

The third is a mid-level plan, which is at the task-day-team level. This allows you to explain to the project team what they need to do and when, every day. Why every day? Because this allows you to squeeze the plan, and shorter projects have better time to value and lower cost.

4) Have a communications plan and stakeholder map

This can be very straightforward, but a Suite on HANA project will have eyes from many places in an organization, and rumor travels faster than the speed of light. Decide who, how and when to communicate with, and do it regularly. I find that CIOs and other senior leaders often like a short weekly update - my rule of thumb is it should be readable with one swipe of the finger on a smart phone.

A weekly 15 minute all-hands call can be useful too - for anyone interested in getting an interactive update.

If you communicate regularly to all your stakeholders then you dramatically reduce the chances of misinformation spreading and causing disruption to your project.

5) Have a production-sized sandbox/pilot

The details of how this works will depend on your organization, landscape and complexity but once you enter the main development system, you will have a change freeze. The best way to keep this change freeze short is to be prepared, and you can't be prepared unless you have previously completed a production-sized migration.

So take a system copy of the production integration environment (BW, ECC, PI etc.) and then migrate the ECC system to HANA. Let your Basis team do this 2-3 times before you release it to the technical and functional teams if possible, so they can hone their process.

It's also possible to do this early on, prior to purchasing all the hardware (buy one sandbox which is roughly sized using the SAP Sizing Guide). If you do this, you can validate sizing so you have confidence in your Bill of Material, and do things like archiving and data aging to reduce your hardware requirements.

6) Consider having some skin in the game from SAP

SAP Active Global Support (AGS) and Professional Services Organization (PSO) have merged into one group, called ONE Support. Regardless of whether you are a Max Attention, Active Embedded or Enterprise Support customer, you can contract them to be involved in the planning and support of the project. In particular they have a service catalog available which has a service for planning and for custom code management. There are free services for pre- and post-go-live checks which you should book in 6 weeks ahead of time.

Having SAP bless your architecture, sizing and plan is a big bonus and they have good quality resources for this sort of work. In addition, there is a HANA Ambassador program available in North America which provides a resource which reports into the Global Customer Office at SAP. It's a good way to ensure your project gets the attention it requires.

7) Join the Customer Advisory Council

There is a HANA Customer Council run by scott.feldman which meets periodically. It's available free of charge for senior IT folks and project sponsors to go and talk to other customers and hear what's going on in the ground, and gain some additional confidence. More details including Information on this Council plus how to join the international HANA Global Community can be found at in this blog.

😎 Change Many, Test Once

This goes against some of the views of IT folks but I am a big promoter of a change-many, test-once approach. SAP has excellent an excellent tool for HANA migrations called DMO, which will upgrade, patch, perform a Unicode conversion and migrate to HANA in one step, all without touching your source system.

This does increase the amount of effort in root cause analysis of problems (which caused the problem) but it provides a single test landscape. One of the biggest risks in any project is inadequate testing, and it allows you to have the conversation with the test team: I've reduce the number of UAT runs from 3 to one, please give me support!

9) Solution Manager is your friend

I don't think I ever thought I'd say this, but Solution Manger is your friend in a HANA migration! There is a SCN Wiki SAP Solution Manager WIKI - Custom Code Management - Solution Manager - SCN Wiki which has lots of useful pages including the tooling available for HANA Migrations.

This includes the Custom Code Management Cockpit (CDMC) which tells you what code has been customized and will break, Usage & Procedure Logging (UPL), which tells you what code is used and how much and Clonefinder, which tells you what transactions have been cloned to custom, and how customized they are.

Custom code is not your friend in HANA migrations, especially clones, because cloned transactions won't get updated with all the nice HANA optimizations that come as part of SAP ERP 6.0 EhP7.

Remember that you need to patch to the very latest version of Solution Manager! Don't take a N-1 approach to this!

10) Test, test and test!

Talk to your test manager and ensure that you have a good test strategy. Do you have separate phases for unit, integration, performance, stress and user testing? Do you have test automation using a tool like HP QualityCenter?

How wide is your test coverage? Does it include front end solutions like portals and external web access?

And remember that there will be some effort in custom code restitution, so leave time to do this. Whilst HANA is an amazing database, it is a columnar database and some custom code will not run optimally if it was poorly written. Row-based databases can be much more forgiving than columnar databases for shoddy code!

11) Build an integrated cutover plan

I've heard so many teams within an organization talk about "my plan". There needs to be "the plan"! The way we do this is to build a cutover spreadsheet with a numbering system and forecast times for every activity, and an integrated playbook which matches the numbering system in the spreadsheet to the table of contents.

Then when you ask the Basis team where they are at 3am, they can tell you what number, and you can see where you are relative to the schedule in 5 seconds flat. You can replace forecast with actual and get a revised cutover plan as you go.

Final Words

Now I've written this blog and looked back on the BW blog, it is fascinating how different the motions are in a BW on HANA migration, but that shouldn't come as a surprise: ECC on HANA is a transactional system, with all the complexities that come with this. It runs the core systems of the most complex companies in the world.

One thing I've missed - it should be implicit - is that in a migration project, you need experienced resources. You need people that know your company, your processes, and external experts. Make sure you work with people you trust and want to work with, and can depend on to buy you a cup of coffee at 3am! And good luck!

I'm interested in your feedback and tips - what have I missed?

P.S. This blog takes me past 15k points to the "Diamond" badge in SCN. Thank you all so much for your support through the years, I truly appreciate your time in reading my work.