SAP produces one of the world’s foremost ERP systems with over 12 million users. As you may have heard, SAP has announced the end of support for its ERP versions that are pre-S/4HANA by 2025. SAP recently announced that it has almost 8000 customers on the HANA platform. However, SAP has implementations with almost a quarter of a million businesses. This means that over the next 6 years just about everyone is going to have to undergo a migration to S/4HANA.
An SAP migration is never a small undertaking. IT leaders across the country are starting to consider their migration path now in order to safely make the company’s deadline.
Given the scope and complexity of the base SAP product, which supports over 25 industry-specific business solutions, and the fact that there are virtually no SAP implementations that don’t have some level of customization, testing needs to be a consideration in planning your SAP S/4HANA migration. To reduce the risk to your schedule, budget, quality metrics, and internal customers, we recommend that IT leaders include formulating testing strategy plans at the same time as your migration strategy.
Testing is often an afterthought in projects. Great testers can sometimes ensure that a project gets across the finish line without too much remaining risk, or shall we say, too large a disaster? But consider the scope of an SAP migration: there are simply too many pieces fitting together that are core to the health of the business for a QA Hero to just push through and make everything ok. There are too many factors at play and never enough time to ensure data integrity, properly functioning integrations, consistent customizations, peak performance and security across the breadth of the SAP application.
Let’s talk about 3 of the most important factors to consider when mapping your S4/HANA journey:
Customization is probably your largest risk factor to consider when you’re looking at the testing as part of your migration. SAP has obviously put a lot of time and effort into their S/4HANA product. As much as the tester in me wants to distrust the quality of a product being shipped, the odds are pretty good that the base product is going to be reasonably stable.
If you have decided to implement the new S/4HANA out of the box and transfer your existing data in, you’ll want to do some smoke testing to ensure that things are working. But many of the SAP customers we speak with have some level of customization and are leaning toward upgrading their SAP rather than starting fresh. This means that whether you have to update your customizations within S/4HANA or have been told the new cloud version covers you, you’re still going to need to test to justify the claim. This will require time and planning. You’ll have to ensure you have the right resources with the right domain and system know-how to model the new system, run regressions, and ensure that your customizations hold and your processes still map properly post-migration.
From our experience, most SAP upgrades come with a heavy dose of regression testing (multiple testers, multiple months) due to the nature of the customizations at play. The bright side is that once complete, these tests can be automated and re-run quarterly as updates roll in from SAP and business demand. Many companies prefer that their regression suite be set up and managed by a third party, so allocating time to select and on-board a partner should be factored in.
2) Test Cases
Another important consideration is your existing testing suite. Do you have a comprehensive suite of test cases that are already developed that will help your testers ensure that existing functionality has not broken through migration? How much of this suite will actually remain the same post-migration in the new Hana world? How much work will it take to migrate your test suite so that it’s still relevant in the migrated system? If you don’t have a comprehensive suite already developed, you’re going to have to determine if you need to invest in creating one pre-migration on the legacy system or if you can rely on user testing, with their existing domain knowledge to meet your needs.
The first is a larger up-front investment but also produces a test suite that can have a very scalable testing resource provider help you come crunch time. It should also give you comprehensive coverage of your business processes. Utilizing SMEs (subject matter experts) from the business can give you pretty solid results in core workflows but they are not always comprehensive in their testing. Nor are they trained to manage issues, document, and triage them as they are discovered. The availability of SMEs can often be unreliable come crunch time and so significant advanced planning and management support is required.
Something that adds almost as much complexity to an SAP implementation as the level of customization are the integrations that have been set up. Virtually all SAP implementations rely upon the ability to get data into the SAP system from other applications, the ability to push data out to other systems, or in the addition of custom apps that make the SAP data more attainable. It is unlikely that these systems will have core support from SAP and you will have to create your own Test Strategy to ensure that you will be getting the expected value from these integrations post-migration. Integration testing in SAP requires people who can define scenarios, design test models, process a large volume of transactions, and document effectively (ideally with S4’s documentation tool—Solution Manager). Then rinse and repeat. It is often the most grueling section of the migration path and one that your IT team is unlikely to relish. This is another area where third party testing specialists can add value and ensure the pain to your IT team and your business customers is reduced.
There is definitely a lot of value to be gained from migrating to S/4HANA. SAP is working hard to motivate its customers to move to HANA and has put a very real timeline around that migration. With the complexity of systems and the resource crunch for skilled SAP experts as 2025 looms closer, smart companies are starting their migration planning earlier rather than later. A major project like this runs the risk of derailing your other IT projects and business initiatives. It’s essential that testing be an early consideration in this process to ensure the continued quality of experience post-migration, pain reduction for your IT team, and impact containment to your business users and user acceptance testers.
Watch for more tips and tricks to successful SAP S/4HANA migrations to come from the PQA team and of course, as always, we’re here to help anyone who needs it in your ERP migration plans.