Skip to Content
Author's profile photo Chris Kernaghan

Running a Proof of Concept – it’s really a good idea (CUUC Series Part 3)

I am great believer in Proof of Concept (PoC) tests, as you can see here, they provide solid proof of an idea and often additional benefits in areas not previously thought about. In the case of the Upgrade and Unicode conversion from my previous post, there were a great many assumptions and things being attempted for the 1st time – so the need for a PoC was evident.

We defined a set of objectives from the PoC to ensure we got the data that we needed, this is detailed in the table below

One thing I firmly believe in is that asking for help is a strength and not a weakness, in this case my team and I were about to run a Unicode conversion on databases which were multi-terabyte and we needed this process to run quickly and smoothly. So from the beginning of the project, I ensured that there was budget to have assistance from Microsoft, HP and SAP if their consulting services were required. When beginning the PoC, I spoke to my friends in the Microsoft/SAP Competency centre about how best to enhance the Unicode process, they were as usual very helpful and technically brilliant. Microsoft provided an ABAP tool called EasyMig, which enhances the table and package splitting abilities of the Unicode process, it does this by using more targetted Where statements within the table splitting routines.

Example screenshots of Easymig Tool

Example of EasyMig statement

“POSNR” <= ‘0000000003’ and “AWORG” = ‘2009’ and “AWREF” = ‘4918931532’ and “AWTYP” = ‘MKPF’ and “MANDT” = ‘100’
“AWORG” < ‘2009’ and “AWREF” = ‘4918931532’ and “AWTYP” = ‘MKPF’ and “MANDT” = ‘100’
“AWREF” < ‘4918931532’ and “AWTYP” = ‘MKPF’ and “MANDT” = ‘100’
“AWTYP” < ‘MKPF’ and “MANDT” = ‘100’
“MANDT” < ‘100’

Example of standard R3ta split

Where (“AWREF” < ‘4918931532’)

The certification status of this tool is in question, as it uses a different R3Load than the standard SAP one due to restrictions on Where statement length, but for the purpose of the PoC we decided it was too good an opportunity to miss and we needed to see how exactly it functioned.

The PoC took a lot of effort, there was much work involved in providing the hardware and the right data set to accomplish our aims before we even got started on the Upgrade and Unicode process. Once we got the hardware and the systems in place, we then had to start work on the preparation of the Upgrade and Unicode conversion – it is important to read the notes associated with your upgrade and Unicode process as these are the fixes to the gotchas you will find. This process takes a few days, during which point you can have the client standing over you expecting things to be moving – it is important to be firm and explain the process and the consquences of not following that process.

Once we got the preparation out of the way and got down to some proper work, we hit a number of challenges, which were interesting to say the least as you can see from the table below.

The PoC was a great success and provided answers to each of the objectives, some positively and negated others, but ultimately there were more positive affirmations than negative – which is always a good result.

From the PoC we moved into the DEV and QAS Upgrades and Unicode conversions, which were done on VMWare environments – these posed their own challenges but I will follow this post with the 1st trial run instead.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Thank you very much for this blog.
      This the kind of blogs which are most usefull : return of experience from a complex real life project.

      We are just beginning our unicode migration/hardware change project so any experience information is gold to us.


      Author's profile photo Chris Kernaghan
      Chris Kernaghan
      Blog Post Author

      Good luck to you on your project, I am happy to answer questions on any concerns you have - no warranty on answers of course 🙂

      You can find me on Twitter as @BoobBoo

      Good luck and happy hunting


      Author's profile photo Tom Cenens
      Tom Cenens
      Hello Chris

      I share your opinion that POC's can be useful and even that they are in fact a good idea.

      The easymig tool looks interesting, thanks for sharing your experience.

      Kind regards


      Author's profile photo Chris Kernaghan
      Chris Kernaghan
      Blog Post Author

      I always insist on a PoC, even though it can increase costs, it is vital to have most, if not all your approach validated from a technical point of view.

      As we all know conditions can change during projects, and these can have technical effects - but because you know how your process works and it's outcomes, you can be more flexible with a higher level of assurance.

      Keep reading - the next one goes through a hellish Trial Cutover 1 🙂


      Author's profile photo Former Member
      Former Member
      Very nice & helpful blog.
      Author's profile photo Former Member
      Former Member

      Short remark: EasyMig tool was on Beta Testing in June 2009, however it was finally not shipped and is not supported. Always follow the official guides released by SAP to perform migrations and upgrades.

      Author's profile photo Chris Kernaghan
      Chris Kernaghan
      Blog Post Author



      I am not sure the point of the remark, the blog is quite clear - EasyMig was an uncertified tool which was in Beta at the time and I do quite clearly state in the blog that it is essential to follow both the notes and the guides.


      In terms of always following the guides, I would say that the pure guides will only take you so far - you must develop your own system specific runbook as an organic process.

      • PoC - Follow the SAP Notes and guides but take screenshots and start building your own document. Following the process, revisit your custom guide for lessons learnt and post upgrade fixes
      • Development - Use your custom guide, but refer to the notes for clarifications if needed. Revisit your custom guide following the upgrade for lessons learnt and post upgrade fixes
      • QAS - Use your custom guide, but do not refer to the notes or the guides - everything you need should be in your custom guide by this point. Post upgrade re-visit the guide for lessons learnt and post upgrade fixes
      • Trial/Mock Cutover - Use your custom guide only. Post upgrade revisit the guide for lessons learnt and post upgrade fixes (If only trial/mock cutover - any significant changes must have a recommendation to repeat the process)
      • Production - Use the custom guide only, everything you need should be in this document - you should not be referring to anything external if it is not explicitly referenced in your document


      To be honest - no-one should be using this specific blog entry as a roadmap for a CUUC process, discounting the fact that it is 4 years old - there have been several advances in the area of Upgrades, Conversions and Migrations which have improved the process considerably. It can and should be used an example of the output and the insights I gained by doing a PoC which greatly helped my process.