Skip to Content

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.

8) 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.

To report this post you need to login first.

28 Comments

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

  1. Thomas Zloch

    Congratulations on the Diamond. Well deserved, always a pleasure to read your pieces and keep myself informed about some of the hotter topics.

    What is the deal with 10 rules in the headline and 11 in the text ? 😉

    Thomas

    (0) 
  2. Sarhan Polatates

    John, again you have published something that I am desperately looking for, many thanks.

    I would like to add mine if you don’t mind.

    Migrate to S/4HANA by having a plan to transform current business processes and considering future business plans of operating industry in .

    Cheers,

    sarhan.

    (0) 
    1. John Appleby Post author

      Thanks Sarhan,

      You know I just commented about the same on Mark’s comment. Business case definition will include the business process transformation. Most customers don’t include any of that as part of the migration.

      I’m interested to see if others agree with me.

      (0) 
      1. Tom Cenens

        Hi John

        Agreeing on it.

        I think customers find it a bit much to do everything at the same time and most prefer a migration as first step without including the business process transformation as part of that step.

        Best regards

        Tom

        (0) 
  3. Mark Chalfen

    Good content – even if you had 11 rules.

    It could be good to compare a traditional Business Suite upgrade so customers who historically moved from 4.6 to SAP ECC 6 – and customers now moving from ECC6 – to S/4HANA (Suite on HANA).

    Also – with my functional hat – when planning an upgrade looking at the new functionality is a must to understand what could be delivered at the same time as the upgrade or in the future.

    (0) 
    1. John Appleby Post author

      Yes I guess you’re right, and I contemplated that after writing the blog 🙂

      I think the reason I wrote it how I did is that most customers doing a SoH migration really look to do the technical migration as one release. They don’t include much functional activity up front other than custom code restitution.


      The functionality should be looked at during the software sales cycle – this is how you create the business case. But most customers defer this until a release after the migration, to keep things simple.

      (0) 
      1. Mark Chalfen

        From the last wave of upgrades the volume of customers that included new functionality was very low, and I totally agree with your view based on historical upgrades.

        However I am unclear if this will be the same when moving to S/4HANA (it could well be the case)

        The reason for this comes from the SAP marketing blurb that says circa 50% of bespoke code could be removed during the upgrade. Now some of this will be old code, but others will be achieved by the new simpler processes (Fiori screens, and new reporting capabilties with S/4HANA). Therefore is there a requirement to review new functionality to help reduce the volume of bespoke code that is migrated to the new S/4HANA environment?

        (0) 
  4. Jelena Perfiljeva

    P. 1 is kind of a bummer for the customers like us – we’ve actually got rid of the BW system. I wrote about it here (shameless self-promotion – hey, diamonds are girl’s best friends too!). Surely you wouldn’t suggest standing up BW just to use as a guinea pig? Any other suggestions on that or are we doomed to just winging it? (Not that we’re migrating any time soon but out of curiosity.)

    Thank you!

    (0) 
    1. John Appleby Post author

      Maybe I framed this wrong. The real question is: how do I mitigate the risk of putting my core transactional system on a technology which is new to my organization?

      Easiest answer: do BW first.

      If you don’t have BW then you have to mitigate the risk some other way. Maybe you do a sidecar instead of SoH first, or maybe you ensure your test plan is just so, and do a POC early on.

      BW just happens to be a neat way to acclimatize to a new database and get all the organizational process assets in place.

      (0) 
    2. Tom Cenens

      2016 will bring in another option, SAP Solution Manager 7.2 can run on SAP HANA and you don’t need a SAP HANA license to run it on SAP HANA. So that gives customers who don’t have the license yet as well as those who do have it, to run a less business critical (in most cases) SAP environment on SAP HANA to get used to SAP HANA.

      For discovering SAP HANA, Amazon AWS infrastructure combined with Rapid Deployment Solution capabilities through SAP Cloud Appliance Library is also an interesting option.

      (0) 
  5. Chris Kernaghan

    John,

    When it comes to planning, I have one thing to say – EXCEL IS NOT A PLANNING TOOL!!!! I have actually had ‘project managers’ come to me and tell me with a straight face that they have a project plan in an Excel spreadsheet.

    Use a proper planning tool which does resources scheduling and dependency mapping so that when something does slip you can model the effect it has upon the dates and deliverables. I worked with an amazing PM who the first week, pulled out the ASAP project plan for the type of project and started filling it out with the team leads and the whole way through the project refined it and tweaked it – but there was one plan in one location and he owned it. It was an inspiring lesson on how to plan and do it right.

    I do think there is room for “Always go latest and greatest” because by the time you go live – you’ll be at N-1 or N-2 already.

    As always as great blog and helpful

    Thanks

    Chris

    (0) 
    1. John Appleby Post author

      Interesting advice as always!

      Actually I believe quite the opposite. Eisenhower said that plans are useless, but planning is everything. It is the act of building a plan which matters, the tool is secondary.

      When it comes to tools, there are so many pros and cons. MS Project and similar do automatic dependency mapping, but they are both hard to use and hard to communicate with. I tend to recommend that the PMO use Project but they communicate to the remainder of the team in another tool like Excel or PowerPoint. But most important is to have something that works for the team at hand.

      Perhaps we can agree that planning tools and communication tools are not the same thing!

      Yes I considered having a latest and greatest point here, but I decided it couldn’t be a Golden Rule because I’ve broken it so many times. In general I think you’re right, but the correct version to go live on depends on so many factors.

      (0) 
      1. Chris Kernaghan

        I’ll give you that planning is everything but my preference is to have a proper planning tool, which will provide the right functionality. The effort does pay off, I have been on both sides of the fence. It’s like trying to run your ledger on an Excel spreadsheet, you can do it, but there are much better tools.

        Project is an awful communication tool, Powerpoint should be used for project status updates and general comms – again the right tool for the right job. So I think we are agreed, planning tools and communication are different things and right tool for right job.

        I also think that projects are too restrictive in the tools that they use – and it always falls to the lowest common denominator and least functional between companies. We need to encourage our customers to be more bold in how they work collaboratively and take advantage of best of breed tools to facilitate better ways of working. Similarly 3rd parties should work with these the developers of these tools to put packages in place which their customers can use safely and with assurance. Although that takes effort and why break something that everyone has suffered through for so long – I thought it was called progress, but I was reminded by someone that it was also called hard work 🙁

        (0) 
        1. John Appleby Post author

          Yeah I mean the root cause is – where is the 2015 project planning tool? It’s certainly not MS Project or SAP Project Systems for that matter (PS has other capabilities that are good).

          I’d hoped SAP would release the Project Planning on HANA pilot I saw, but that seemed to fizzle out.

          (0) 
            1. John Appleby Post author

              Nah, C4P is a Financial Planning tool.

              I saw a pilot of a project planning tool based on HANA and SAPUI5 last year. It was just a lab preview and I don’t think it got out the lab.

              (0) 
  6. Michael Janello

    Thanks for the post, i fully agree and like it !.

    on 6) this is really something you should consider, as you said, the blessing is worth a lot and AGS has great staff to help the customer move through the change.

    in addition i would like to highlight on 9) , or general coding adoption, that dependent on the size of the installation, or the amount of modification/custom code a big portion of your migration project could be code remediation/adjustments. UPL/Usage tracking is key, so is code retirement, otherwise teams will spend a lot of time re-writing unused code/reports.

    for 10) yes, test is essential, especially for the custom code areas which have been changed. in addition one should always consider that test (in production) should also be performed post goLive in terms of performance, we had many findings where adjustments to the actual logic of application was done to use the power of hana (pushing down logic to DB) of course, all should be prioritised based on UPL and criticality.

    thanks, Michael

    (0) 
  7. saee sai

    Dear John,

    can you discuss more about the testing part,

    if S/4 HAN is on cloud, it would be more with web testing

    if S/4 on premise it would be more on QTP

    want you to comment more on this

    (0) 
    1. Chris Kernaghan

      Saee,

      Because S/4 would encourage the use of Fiori as the main user interface, then you could invest in better web based testing frameworks which are highly automated and scalable.

      Products like Load Runner, Tivoli and QTP were important because the SAP Gui was a specific proprietary application, moving to Fiori should enable customers to think long and hard about their testing strategy. Especially when you factor in HCP as the extension platform for S/4

      I would be interested in your point of view though.

      Hope this helps

      Chris

      (0) 
      1. saee sai

        yes Chris,

        try to predict, what it could be, with GUI goes off, it could be more of web testing (not sure about the on-premise yet) which frame work and testing tools would best suit the migration testing

        (0) 
      2. saee sai

        Dear Chris,

        Fiori when on-premise would it be a GUI ? or it could still be a web application

        Fiori on cloud is definitely a web based its clear

        (Fiori is HTML5, JS, UI5 etc)

        (0) 
    2. Tom Cenens

      CBTA (Component Based Test Automation) which is available in SAP Solution Manager can handle UI5 so that’s probably worth looking at (I’ve used it and it’s pretty decent already in it’s early versions so I expect it will only be better in the future).

      (0) 
  8. Robert Weber

    Hi John,

    many thanks for this guideline.

    The topic which I would like to add: Allow to make mistakes during the project. Only on mistakes (and the resolution of those) you really learn a lot.

    And you are well prepared for the operational tasks and challenges once the system is running.

    Thanks for sharing your ideas with us.

    Regards,

    Robert

    (0) 
    1. ASISH K MOHANTY

      Hi John,

      This is a  very good approach as part of SAP BW  on HANA  with excellent database back_up  recovery , disaster recovery of entire SAP  and Non SAP  database . 

      This is a  best Agile method practice for any Central  ERP warehouse project migration plan for running with HANA DB to  keep boost a global Project plan for all SAP Module , which will give better performance to client ,stakeholder with a outstanding benchmark in

      development, QA/QC analysis phase .

      Cheers

      Asish

      (0) 
  9. Patrick McCarthy

    With this you have earned your Diamond!!  Most of this I already know, but having it put out there so well and to the point makes ‘selling’ a difficult decision to the SAP staff, especially the functional side far easier.

    Pat

    (0) 

Leave a Reply