Planning SAP S/4HANA Migration: Preparing Your Code

Abstract: Before you launch an SAP S/4HANA migration, you must first prepare your code with thorough assessment and planning processes. This means that Software Architects/Engineering Managers must assess all code units of their projects in order to understand if they are ready to be migrated (e.g., if there are important errors to be resolved) and to be able to plan the execution based on priorities and dependencies (according to the teams available). Within the planning process comes the decision of whether to adopt a Greenfield or Brownfield strategy, where Greenfield means that there is no need to remodel or demolish the existing structure and Brownfield means that the project (codebase) should be upgraded or modified. Through all of this, Seerene offers the transparency that helps you evaluate the current situation in your codebase and make fact-based decisions as you prepare your code for the migration process. 

• Introduction
• Initial Assessment 
• Greenfield or Brownfield? 
• Determining Resources
• Progress Reporting

Introduction 

So if we look at SAP HANA migration, there is a whole process around it that requires you to understand what your software development or SAP system looks like, where you have business functionality, where the development activity is happening, where you have  ABAP Test Cockpit (ATC) errors that need to be resolved to make the system run on S/4HANA, and also to make the decision of whether to go with Greenfield or Brownfield. This decision can be quite daunting if you don’t have data, and it takes considerable time to truly get an understanding of where you are and what systems you have. Getting these answers into a consumable format can be very challenging. This is what we start with during the assessment phase and it’s necessary to have completed it before getting into the planning phase.  

Initial Assessment, Identifying ATC Errors

Migration Preparation: As a Software Architect [Engineering Manager] you need to assess all code units of your project in order to understand their level of migration readiness and be able to plan the execution based on priorities and dependencies

Assess: Support conscious decisions with data on the current situation of the system and recent development activities. 

1. To identify the most relevant applications for an SAP migration, look at what ranks as the top five applications for Logic size and for total effort. HANA migration should happen on a system that contains significant business logic and that is relevant regarding software development efforts.
2. Assess the Application: Use the "Logic Size" KPI in the Application Scorecard and observe the progression of Logic size over time. Select "&Effort in Complex Code" and "%Effort in Defect Fixing" as KPIs. If there is a consistent increase of business logic, it is a relevant system where they currently implement business process logic. If they spend a significant percentage of their effort in complex code, an investment in the migration might have benefits from an IT perspective as well. If from a risk-perspective, the risk is there, it is important to keep this measure of risk in mind while planning.

Leveraging the Seerene Platform to Prepare Your SAP S/4HANA Migration

The Seerene Platform and the Seerene Digital Boardroom can be used to simplify the S/4HANA migration and to ensure code quality. Use the Seerene Platform to:

• Locate: Determine which parts of the code you need to improve before migration.
• Prepare: Identify the most critical code units regarding ATC errors, warnings, and notifications by comparing the numbers . Prioritize based on the ATC values and urgency.

What to do: Within the Seerene platform, move to list view, adjust the list to the desired level of granularity . Sort the list and study the KPI values. As a Software Architect [Engineering Manager] you need to lead the team to remove all ATC errors and,  if possible, warnings and notifications of specific code in order to make it ready for migration.

Use the Digital Boardroom to conduct a team meeting for constructing your migration plan and assigning team responsibilities:

• Ensure access to all ATC reports as well as to the development environment.
• Discuss & define targets with teams, decide reporting frequency to ensure project plan stays on its timeline regarding ATC fixing.
• Ensure that all ATC errors can be corrected by responsible teams and that all teams are aware of planned timelines, targets, priorities, and monitoring/reporting processes. 
• Find specific problem code using map filters; the most important of which is the code folder. Assign the code folders to your teams and educate them on how to use ATC KPIs. Create ATC dashboards for each team to track progress. Grant access to all team leaders to the analysis tools.
• If you need to examine ATC KPIs more in-depth, you can use the Software Maps from Seerene to jump to the relevant source code.

Greenfield or Brownfield?

When transition to S/4HANA, there are two key options:

1. Either implement S/4HANA from scratch and migrate your existing data in a Greenfield approach...
2. Or, alternatively, you can transition your existing ECC to S/4HANA, including all of its customizations and data, in a Brownfield approach. 

The decision depends on data quality/Unicode/archive:

S/4HANA only supports Unicode; if your ECC system was on multiple code pages, a Unicode conversion would have to be included into the transition. 

Generally, those with a streamlined system of code, data, and integration can adopt a Brownfield transition to S/4HANA. If it's relatively easy for you to streamline your system, then this is also an option for you.

For those with lots of technical debt, a Greenfield migration is probably the more feasible option, with a simplified, clean end result.

Determining Resources

Now as you enter the planning phase, you should what developers have been active in prior software development. The question is who and how many have been active in this area of code. If only one developer has been working in this code, then you might have a knowledge monopoly, meaning you probably can't proceed as quickly as you'd like. In a situation with multiple developers or teams having worked in the relevant code, you of course wouldn't have the same issue with developer resources. With Seerene Software Maps, you can identify how many people have worked in the relevant code recently and how the knowledge is distributed; thereby allowing you to identify potential bottlenecks in the migration.

Should only one or very few developers have the expertise and experience to work in the relevant areas of code, you can take this knowledge gained through Seerene and find another approach, including involving more developers so that a bottleneck doesn't halt your progress.

Reporting on Progress to System Owner

To ensure that the migration is progressing on schedule and that developer resources are allocated as needed, it's important to implement the appropriate reporting. Follow these steps in your Seerene Platform:

1. Setup monitoring by adding pinned widgets with code unit filters for ATC errors on dashboard. 
2. Monitor high-level progress by observing the dashboard widgets to track the overall trends.
3. Drill into the details if questions arise. Click on the dashboard tile to drill into the map and look at revision activities, etc. to find out more.
4. Upwards monitoring on overall progress: Upwards reporting is done on the entire C3PO application. Take a screenshot of the dashboard tiles on ATC Errors and ATC Warnings and send them in an email if an issue arises.
5. Ensure project goals are reached and the timeline is followed. The “Steering: ATC Warnings Reduction” target widget provides current values and predicts if the overall timeline goals can be met at the current pace.