SAP S/4HANA Migration Preparation Guide | HCLTech
Digital Business

With SAP S/4HANA migration, preparation is everything!

Top 20 recommendations of critical activities that will help ease migration to SAP S/4HANA and add real value to preparation work ahead of a planned SAP S/4HANA upgrade.
 
8 minutes read
Ray Gardner

Author

Ray Gardner
Solution Director, SAP Practice, HCLTech
8 minutes read
Share
With SAP S/4HANA migration, preparation is everything!

You don't have to wait for your upgrade project to start preparing for the move to SAP S/4HANA.

Many preparation tasks are worth undertaking even if you don't (yet) plan to move to SAP S/4HANA. This is because many preparation activities are also sensible ways to improve system quality and consistency, improving your current system's day-to-day use and operation.

Because all companies can benefit from early preparation, I'm sharing my top recommendations of critical activities that will help ease your eventual migration to SAP S/4HANA and add real value to preparation work ahead of a planned SAP S/4HANA upgrade and any gradual implementation of newer . And remember, it's never too early to start exploring the scope, strategy and initial aims for your future solution!

Understand the importance of early preparation.

It's hard to underestimate the importance of early preparation work. Once an upgrade or implementation project starts, the program team will work to a potentially tight timeline and often within a fixed budget. Preparation can avoid risking delays that could have wider impacts.

However, early preparation tasks can also improve understanding and operation of the current system. A classic example is to address Data Volume Management (DVM) to reduce the current database (DB) size, which helps speed up current processing times and reduces costs incurred from the physical system size.

My original aim was to develop a top ten list, but given the scale of what can be done, I struggled with such a short list! So instead, here is my top twenty list of preparation tasks you should start now:

  1. Business process scope: Confirm which business processes are used — and understand their business flows in detail — within the current system. This will also influence how the scope can be realized and tested in a new SAP S/4HANA-focused solution. Process analysis may sound daunting but can be eased by automated analysis. We use tools such as Signavio or Celonis as part of HCLTech's Business Transformation Framework to rapidly address this in our methodology.
  2. Organization and data model understanding: This includes organizational structures, data model fundamentals and any company-specific modifications or specialized usage. Since the upgrade is a point at which some level of organizational change and data model re-work can occur to support future flexibility (or move back to more standard options), this opportunity must be fully investigated to ensure the right foundations are set.
  3. Known or expected constraints: While the current state may be ascertained fairly quickly, additional effort will be needed to identify future needs or considerations. This could include constraints on the business design through to the technical solution or more general corporate considerations that need to be considered. These can cover a very wide range of items and be very specific to the company; hence, understanding and detailing these will be key to guiding the target solution.
  4. Core requirements: The solution will often be assessed against a fit-to-standard approach, where the business is shown standard processes to confirm these can be adopted. While an entire requirement-led project approach or complete process decomposition is not required, you still need to define critical requirements, including a basic level of underlying core functional and non-functional requirements. I recommend including two main areas:
    1. The solution must support the high-level process areas, including any new functionality and/or features and any key improvements that SAP may offer that the business wants to adopt.
    2. Requirements for, and including any potential early use cases, for applying innovation options. For example, higher automation, use of AI or Generative AI(GenAI) or more technical areas such as DevOps, citizen enablement (i.e., Low-Code/No-Code) or increased side-by-side application or service solutions.
  5. Cost influences: Understand the main factors that lead to the current Total Cost of Ownership (TCO) and the current license position and how these can be used or reworked into a target solution. For example, newer or updated financial methods or options (such as ) can be adopted, and any preferences in these areas must be assessed. Understanding new options can be tricky for internal teams, so I advise engaging a partner early. For example, HCLTech has a Value Sentinel framework, license assessment and cost analysis tool for RISE and services to help in these areas.
  6. Best practice knowledge: Business users and functional architects need to become conversant with SAP's best practices, which are now fully documented and supported by process flow underpinned by recommended configurations and test cases supplied by SAP. Entering a preparation phase with a detailed awareness of SAP's Best Practices will help show what SAP S/4HANA can do, what simplification and shifting back to standard may look like, and, importantly, inform your business case.
  7. Innovations, new features and Lighthouse solution awareness: While it can be tempting to sit on your current ECC solution, a more comprehensive understanding of what SAP (and specifically SAP S/4HANA) can now deliver and how this could be transferred into more effective business processes, use of resources or capabilities to support business transformations, is needed. The best way to get to grips with “new” SAP concerns a working system, direct system demonstrations and relevant SAP client use cases. This will help you identify any overlapping solutions, be more tactical in delivery and help consider a possible future shift back to standard after any upgrade.
  8. Strategic preferences: Review and update your organization's strategic preferences from a business, functional or technical perspective, covering solutions, tooling, services, methods or expected available options/ skill sets. These will form a contextual foundation for the upgrade.
  9. Differentiations: Historically, any gaps or functionality extensions were delivered within the SAP tool set. Today, the approach is more focused on maximizing available functionality and applying extra effort only in areas where real business differentiation is needed. There are options to refine functionality, solutions or business interactions/experience. Yet, the challenge now is to realize this in a supported and managed manner, leaving a clean core (and easing future upgrades).

    Identifying where the business or company truly wants to differentiate is thus a fundamental governance step. Any current developments can thus be assessed to confirm if the extra work/investment needed to include them in the new system should be approved. We support this assessment using our FENIX 2.0 framework, which ensures the business has visibility and control of where to invest in differentiation.

  10. Building the business case: The upgrade's cost, value, budget and overall business case are fundamental to launching a program. SAP and companies like HCLTech can assist you in this area. Our experience is strengthened by being the first large SI to implement RISE with SAP internally for our own -based solution upgrade.
  11. Obsolete solutions: Understanding what is present in a system and what is not needed is a valuable preparation item. Many current systems have a footprint of older configurations, code, data or even organizational units. However, organizations often overestimate what can be made obsolete and no longer used. For example, specific use cases, occasional reference data or information for occasional or annual use may get missed.

    Remember to cross-check obsolete master data to the actual transactions (i.e., open items or required transactional retention items) since this will be a cross-checking method for exclusion/inclusion. Even if data may be many years old, there may be valid reasons for its retention, so detailed checks with the business are needed. Also, data may be held in analytical layers or specialized retention solutions to avoid excessive data in the operational system. Hence, being clear about what is obsolete is critical.

  12. Data Volume Management: Preparation can cover many areas of data (including understanding the organization and data model covered above). Data Volume Management is about managing the current data to see if there are opportunities to avoid ongoing data build-up, housekeeping tasks to reduce data volumes and data archiving to remove offline data when required. This can reduce the current DB size and, thus, current costs and minimize the future in-memory system size.

    It's worth remembering that there are many options to avoid data build-up and/or housekeeping beyond archiving that often get missed and these can usually be quick wins.

  13. Data quality: For the remaining in-scope data, quality needs to be checked and, when applicable, improved to support an upgrade. This means establishing key metrics and defining what ‘good’ data is. For example, HCLTech can show how current tools/features can be maximized to address data quality. Also, I'd recommend investing further in data tooling and solutions since all solutions rely on high-quality and cleansed underlying data.
  14. Data preparation: This can include additional data readiness items, such as confirming exactly what data selections must be used to identify the in-scope/actively used data correctly. Additionally, data enrichment or extension into updated business use or SAP data concepts needs to be completed. Thus, data preparation must cover items such as SAP's Customer Vendor Integration (CVI) tasks or extra data that may be required for new functionality (i.e., customer credit management or correct/updated use of material class and characteristics).
  15. Simplifications: SAP supplies a range of functionality that has had simplification, which can change how those areas of functionality work and are used. Awareness of these can help prepare for these changes and ensure the business stays within SAP's recommended roadmap. This can also ensure that companies do not invest in areas with changes and simplifications (and benefits) already factored into SAP's product and/or roadmap.
  16. Confirm bespoke solutions use and applicability: Much of your bespoke configuration, code or system use will likely have evolved over time. We often find that a very significant portion of this is not actually used or is sometimes used differently across the organization. Thus, identifying what is used and/or needed and with what data, transactions or analytics is critical to the upgrade.

    To help companies address this historical technical debt, HCLTech uses our HANASmart tool to show code usage and supplement, extend, guide (via AI) and automate development corrections, refactoring and re-platforming. SAP tools, such as the SAP ABAP Test Cockpit (ATC), can also help.

  17. Understand changed technical designs, practices and methods: The use of SAP's Business Technology Platform (BTP), which includes more agile and experience-led design; how waterfall developments can be more hybrid; and delivery of “side by side” solutions are just some of the newer concepts driving SAP delivery. With increased automation, AI, GenAI and other emerging options, agile and DevOps-style delivery must also be factored into SAP delivery. The patterns of technical delivery that a citizen-based developer may use and also how this will be delivered via SAP tools (i.e., in an SAP opinionated manner rather than possibly a more open cloud-first approach) need to be understood, and some high-level recommendations and guidance provided so that there is consistency in delivery.

    Taking your technical teams and architects through what this can mean to them is a critical part of the journey to SAP S/4HANA. For example, Leaving code in-app or just shifting ‘as is’ to BTP misses the opportunity to refactor solutions to a clean core, simplify technical debt and reduce tightly coupled solutions. While all of this re-work may not be possible in a single upgrade, earlier preparation or post-upgrade (potentially as a follow-on project or in support) can help address this and continue to ease ongoing upgrade challenges.

  18. Updated integration: While there are several new options for developing solutions with SAP S/4HANA, such as individual apps through to complete cross-functional applications, there is often a fundamental shift in the underlying integration that can support both new applications and wider system integrations.

    Integration needs to support Complementary Off The Shelf (COTS) solutions, interfaces with corporate systems or services and many more emerging areas. The range of integration styles has expanded; integration can be “point to point” or through APIs, events or aligned EDI with trading partners. The critical point here is the older design patterns of sharing master data across the landscape and facilitating multiple transactional flows across systems via tightly coupled integrations do not have to be the default approach.

    For example, integration can now provide APIs for direct use via a more focused set of APIs that can be used in real-time in a more decoupled solution design. These solutions can also react to business events and provide real-time analytics with intelligent or AI-enabled solutions. So, take time to re-assess your integration options to support the newer design and consumption options required in a more open, cloud and intelligent landscape.

  19. New system access: To really prepare for SAP S/4HANA, the best option is for critical resources to get familiar with what SAP S/4HANA can provide. Accessing a system enables hands-on use and first-hand experience with new features and functions. SAP and companies like HCLTech can help provide access to working systems, including the development platform. HCLTech further supplements this with our physical or virtual labs (called ideaX). However, demand can be high for these sorts of options. This should not put you off; it just reflects excellent demand, and thus, an organized approach to assessing functionality or specific technical use cases can help focus on what can be best achieved from early system access and use.
  20. People: In many ways, the most critical item is people's preparation. However, this is the most frequent item and is only to be addressed once a physical upgrade project has been initiated. Identifying training, skills development and early building up of SAP S/4HANA knowledge and investing in developing skills are essential. Addressing this can also be critical to help retain your crucial staff even when the upgrade may still be some way off.

    Many of the newer concepts and even some of the newer SAP S/4HANA tooling or solutions can also be used and applied with ECC. Many companies implement a range of SAP solutions ahead or in parallel to the SAP S/4HANA migration, such as SuccessFactors, Concur and Ariba and use of technical solutions such as BTP, so these are areas for early preparation and can help educate and retain your key people by exposing them to newer SAP technology and capabilities.

The above is just a brief introduction to these items. Applying this list to real scenarios will always require specialized input.

If you are specifically interested in some of the typical challenges and opportunities around ECC to SAP S/4HANA preparation through complete upgrades and post-upgrade realization of a clean core, please check out my other blogs and contact HCLTech to see how we can assist you.

Share On