Routes to Azure
I have recently delivered a number of sessions talking about SAP HANA migrations and S/4HANA conversions into Azure. There have been requests for a bite-size version of the session for those who were unable to attend, so here it is…
I based the first part of my session on this graphic from Microsoft:
Whilst I’m not going to go through each of these options in detail in this blog, (you’ll have to watch the recording of my session for all that content!*), I am going to tease out my top tips for approaching migrations and conversions.
When it comes to migrations and conversions, my key message is that there is no ‘one size fits all’ approach. There are many more options than the 4 shown in the diagram above, but we need to start somewhere.
There are several things that you should be considering regardless of your migration or conversion approach, and these should be looked at before you start anything else.
SAP quite rightly insists that you should always use the latest available version of the SUM tool. It is recommended that you also use the latest agents and kernels on your source system and where possible you go to the latest version of the target system components too. Sometimes an organisation will tell me that they have an N-1 approach for patching or upgrades, where you go for the release before the latest release.
Ultimately that’s down to your organisations patching and upgrade strategy, but this isn’t how you leverage the best from the tools. It’s always worth taking a look at what additional features are available if you did use the very latest versions; it might just be enough to convince the organisation that it’s worth the risk in order to significantly reduce the downtime.
For example, with a conversion to S/4HANA 1909, we now have the ‘Shadow On Target’ as an option, which reduces the impact on your source system. We are also seeing the introduction of silent data migration features, which allows the migration of application data during uptime. So being able to leverage the latest innovations in the toolset could ultimately save time and money on your migration and conversion.
Other considerations before you start, include deletion of languages that aren’t being used, cleaning up obsolete systems and clients and the deletion of obsolete add-ons.
Archiving has to be the most overlooked aspect of pretty much every SAP implementation I see, and it doesn’t need to be complex or time-consuming. Setting up archiving on just a few key tables can make a world of difference to the speed of migration or conversion. So don’t discount it as ‘too hard’ because this will also benefit you both during a migration/conversion and also after you have moved to Azure in terms of reducing your database footprint which in turn leads to lower costs.
Your source system hardware could be a bottleneck. If you don’t have sufficient resources to allocate your source system, you are likely to impact production during uptime and lengthen your downtime phase. So check what you have available upfront and plan your strategy accordingly.
Start looking at your custom developments, modifications and enhancements early; what can you get rid of? Don’t take all the old rubbish with you! There are tools from SAP to help you with this.
There are also considerations relating to what you want to do in terms of the target system. If you are on a non-Unicode version of ECC6 and want to go to S/4, for example, you’ll need to do a Unicode conversion beforehand, you can’t do that as part of the S/4 conversion. You may also need to do a dual-stack split and/or an EHP update. Your starting point directly influences the options available to you.
Just to add a final layer of complexity to the considerations, with a migration to Azure, you need to be carefully reviewing the Azure supported products and SAP supported scenarios. Not every version of every OS and DB and kernel is supported in Azure. So if you are planning one of the first two options, where you move your systems ‘as-is’ to Azure initially, be aware that you may have to run a programme of patching on your source systems before commencing the migration to Azure.
So the actions you need to take depend entirely on your source system and target system combination and it can be quite a challenge to work out the details of what you can and can’t, should or shouldn’t do.
SAP HANA Migration and Conversion General Recommendations
There are also some general recommendations I’d like to share with you.
- In order to sufficiently test, you need to have a test environment that is representative of production for dry runs and also for functional testing.
- Ideally, perform a refresh of P to Q before starting your conversion project (if one has not been done recently).
- Create a sandbox, ideally as a copy of production, in order to run through the simplification checks, custom code migrations etc. You can then also use this for the ABAP test cockpit once you have converted it to S/4HANA
- Allow time in your plan to run multiple iterations of the technical conversion process to fine-tune the steps, document fixes for known errors, tweak parameters, work process allocations etc. The dry runs are about minimising risk as much as possible, ensuring there are no surprises for the production migration and conversion.
- Optimise your migration/conversion by parameter and work process tuning; try different options out. You can adjust work process allocation on the fly in SUM so experiment with it.
I’ll say it again; use the latest versions of the tools and products in order to utilise the latest developments and features.
What do I mean by ‘don’t be afraid to use Azure resources’?
Well, let me give you an example. With one particular S/4 migration to Azure we worked on, we found the SGEN was taking a very long time – in fact, it was estimated to take approx 8 hrs. So as a bit of an experiment we massively ramped up the VM resources and the SGEN finished in 15 minutes. We then reduced the resources back down and the downtime was significantly reduced.
Tools to Optimise Downtime
It’s also worth mentioning tools briefly, as your migration or conversion path may be influenced by the tools available, or not available to you.
Since SUM 2.0 SP02, near Zero Downtime Maintenance has been available for S/4HANA conversions, but the source system database needs to be on HANA already. nZDM can offer a significant reduction in downtime by utilising the ‘record and replay’ technique for business transactions. So if you have a very large system and are struggling to reduce the downtime required for a single step transformation to HANA and S/4HANA, (option D on the first diagram), then you might need to consider migrating to HANA first, in order to utilise the nZDM features of SUM to reduce your downtime requirement to an acceptable time frame.
From SUM 2.0 SP06 we were introduced to Downtime Optimised DMO. There are a number of restrictions to using this, so read the notes carefully, but from SUM 2.0 SP07, the target of SAP S/4HANA 1909 is now supported.
If you cannot achieve the necessary downtime with the standard SUM tools, parameter and work process tuning you may need to engage SAP for more specialist services.
For example, the Near-zero downtime technology service from SAP, (not to be confused with nZDM), uses a clone-based methodology. Following the cloning of the production system, DMO executes on the clone. Transactional activities are captured from the production system and replayed back to the clone system. This means during downtime, only the remaining changed objects need to be copied, thus dramatically reducing downtime.
Downtime optimised conversion is a S/4HANA specific service from SAP targeting 1809 FPS 01 and above. It essentially migrates some of the application tables such as FIN and material ledger and inventory management, KINV and VBFA tables during uptime.
Zero Downtime option (ZDO) is a S/4HANA specific optimisation service from SAP for patching S/4HANA systems. Again, lots of restrictions and pre-reqs for this. It’s available as a pilot project with SAP and has to be requested.
So, to summarise…
- Spend time at the beginning of your project analysing, rationalising, archiving and deleting; it will save time and money on your migration and ongoing run costs in Azure.
- Use the latest versions of the tools and products where you can to leverage the new downtime optimisation features and enhancements from SAP.
- Run multiple iterations of your migration and conversion so there are no surprises when you come to the production system cutover and don’t be afraid to experiment to find the optimal settings.
It is very easy to feel a little overwhelmed by all of the different pathways and options available for a HANA migration and a S/4HANA conversion. As I said at the start of this blog, there is no ‘one size fits all’ approach, no two customer engagements are the same. That is why you should be considering engaging with experienced partners, like Centiq, who can help with the design and the successful delivery of your HANA migration and S/4HANA conversion projects.
If you’d like to have a chat about your options, we’d love to hear from you.
For more insights from this author:
Centiq’s SAP Basis Consultant, Claire Richards, takes us through the complexities of the SAP HANA landscape and the skills gap a lot of organisations face when designing, deploying and optimising the platform. Watch the video here.
*To request the SAP on Azure Immersion Workshop video please email here.