Skip to Content

I blogged last year about a programme of work to run several upgrades  and Unicode conversions on multi-terabyte SAP Systems for a client.  Finally I have been able to pull together a series of posts which will  detail the work, the challenges and the solutions we implemented during  the programme. The upgrade programme lasted for 10 months and covered a  number of projects,

  • The upgrade projects (Listed below)
  • A Data Centre migration and support migration to an outsourcing supplier (Run by the client and the outsourcing supplier)
  • Hardware migration (As part of the DC move)

These blogs will focus on the upgrade of the ECC system, for the  simple reason that it was the one I was closest to, although I will talk  about the other upgrades and the challenges they posed. At the start of  these projects it is important to have strong idea on how to execute  the upgrade and Unicode process, I use the word idea because at this  point it is an idea; it has not been validated by anything other than  experience from other projects. I looked at the overall programme of  work being executed at the client and the client’s roadmap for the  future and developed an end-point of where the systems should end up at  the end of the project – this is detailed in the table below

Once I had decided on the versions of the O/S, the database and the  SPS levels of the applications, the main consideration is how do you get  to those versions. The SPS levels are quite easy as they can be  integrated into the upgrades and handled during the upgrade runtime. The  O/S and DB versions changes are usually handled outside the upgrade  process, but they can be interwoven with Unicode conversions depending  on the scenario and so it is important to look at what else is going on  within the landscape to see what options are available to you to achieve  your aims – for me my saving grace was to be the data centre migration.

The diagrams below show two options available to achieve the O/S and  DB versions, using the Unicode conversion and another doing it  seperately.

  • (Notes: The colour of the servers is important as it reflects a change of hardware
  • IA64 – Itanium Processor architecture
  • X64 – X86 64Bit Processor architecture
  • NUC – NonUnicode
  • UC – Unicode)

Below is a table which details the agruements for and against each approach and you can quite clearly see a winner

There is one factor in all the of the discussions about options above  that I have not dealt with, and that is the database size. Database  size is a major driver as to which method of conversion you undertake,  the larger the database and the longer it takes to convert – that is a  fact. Not all databases are created equal, different vendors, different  versions, different levels of administration all play their part in the  Export/Import timings, but still data volume is the kicker – in this  project a 4TB database had already defined the process as parallel as  there was not a big enough window to perform the Unicode conversion as a  serial task, the question now was just how much parallelisation did I  need to use.

The next post will deal with the actual PoC process and what we found out running it.

To report this post you need to login first.


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

  1. Sachin Digamber Pokalwar
    Thanks for sharing this wonderful information, would like to add some more points out of my experience.

    You mentioned about the options for Unicode conversion & OS/DB Upgrade.  Both the scenarios are only possible if your existing environment is single code page, as ERP 6.0 doesn’t support MDMP.

    In the comparison table you did discussed about parallel export import & mentioned as complex procedure, yes its comparatively complex but if you plan to distribute the load (Migmon) or carry out some package splitting/table splitting. If you only perform only parallel export/Import it’s relatively simple.  

    You may also want to consider the CU&UC approach where you will perform all in one step, I understand that this will be relatively complex as we are performing all the tasks together but as you mentioned if you plan well we can achieve that.

    Looking forward for your next blog.

    Best regards,

    1. Chris Kernaghan Post author

      Good to see I am being held to account by another Upgrade and Unicode person 🙂

      You can interweave an O/S and DB upgrade into any Unicode conversion, because the export does the conversion to Unicode and outputs to file structures. This is then picked up by the Import, and handled just like any system build. I have done an MDMP conversion and it functions broadly in the same way as Single code page, the main difference is the Vocabulary handling. This is of course dependant on the versions being supported by SAP.

      The essence of parallel Export/Import is to distribute the load, and the concept of doing it is simple. Although like most in this life, once you scratch the surface the details are many. In my experience, downtime windows push people to parallel Export/Import. As a result it needs to be optimally tuned to make sure the expensive investment in it is fruitful. So from that regard, I always expect to tune the Export/Import process using table and package splitting – otherwise why do it. I cover this in a later blog in the series, the

      It is implicit that we are doing CUUC, I have blogged before about doing Split conversions and the lack of value of them, you are right though that it is not explicit yet – it will be clear in the PoC blog I have written.



  2. John Appleby
    Hey Chris,

    Lots of great points here, and I think what you’ve done is to highlight that there isn’t a right or a wrong way to do this complex process but instead what’s important is to choose the right way for your situation.

    Certainly choosing the cheapest approach might be right for some customers, when database size is small and downtime is not critical.

    Or on the other hand it might be appropriate to run parallel instances so you can have near-zero downtime, perhaps in a manufacturing scenario when downtime means production standstill.

    I’m not 100% with you on CUUC by the way – if you’re considering doing a hardware migration in the next few years then it might be easier to do the Unicode Conversion with the platform migration rather than the upgrade. Otherwise, I’m totally agreed.

    But the main point that comes out is that SAP Landscape Architecture for upgrades, migrations and hardware refreshes has a lot of variables and having someone knowledgable consider all of them for you adds an enormous amount of value.



    1. Chris Kernaghan Post author

      You’ve hit the nail on the head, the approach depends greatly on the project requirements and you must look beyond your own deliverables to view the client’s roadmap and how you can best help them achieve that.

      As regards the CUUC and Split (Twin Approach), these are purely Upgrade focussed scenarios. If there is a hardware migration that can provide an additional win through a Unicode conversion and the budget it there to finance it – then absolutely go for it.

      The main objections I have to the Twin approach for upgrades are,
      1. It involves 2 sets of downtime, the scheduling of this 2nd downtime is problematic, as it needs to be close to the 1st so as to not lose momentum. but needs to be far enough from it to allow the team to recover, the business to run processes and allow the system to stabilise.
      2. It requires seperate remedation of the systems, so transports do not contain Upgrade and Unicode fixes which can complicate change management.
      3. It requires seperate testing phases, increasing costs and project timelines.

      But mostly because the tools to complete a CUUC are fantastic and under active development – there are an array of options for tuning the processes. (My new fun toy is an automation engine, which allows me to parallelise post-upgrade/pre-Unicode steps to reduce timings further)
      If downtime is such an issue, the the client needs to look long and hard at the Incremental approaches offered by SAP – the Near-Zero downtime services.



      1. John Appleby
        Totally agree, although I think the point is when we architect an upgrade, we should also think about all the other possible things that might happen in the future. Unicode, hardware replacement, new functional or non-functional requirements like HA & DR. Backup strategy. Performance. It’s only when we look at everything holistically that the best overall upgrade strategy becomes clear.

        But most of the time CUUC is the way forward and the Twin approach is outmoded. I believe in the “change many, test once” approach too – this year we did one 5TB database where we did hardware migration, Oracle upgrade, Unicode Conversion and Upgrade all in one downtime window. For them, a single longer downtime window was preferable.

        The Automaton Engine. What a great name for a band.


Leave a Reply