AFS to S/4 Data Migration: Seamless Transition Achieved by a UK-based Leading Fashion Brand

The value chain in the fashion retail industry is evolving at a rapid pace. Retailers are successfully executing backward integration by manufacturing & launching their private labels. Manufacturers & wholesalers are busy integrating forward in the value chain by opening their retail outlets. SAP Apparel and Footwear Solution (AFS) and SAP Retail solution, envisaged to solve business challenges of two separate segments of the value chain needed a facelift (Read Now is the time to move: migration from AFS to S/4HANA for fashion and vertical businesses). With organizations integrating their value chain and becoming vertical businesses, the need for a unified platform was evident. S/4 HANA for fashion aimed to resolve this challenge.

Our client, a UK-based global fashion company and a footwear manufacturer for one of the world's leading sports, outdoor, and fashion brands, made a strategic decision to migrate from their SAP AFS to S/4 Fashion and chose Applexus as their implementation partner.

Data Management plays a key role in AFS to S/4 Migration

Migrating your system from SAP AFS to S/4 Fashion is very different from other S/4 Migration scenarios from a Data Management perspective.

New Implementation focused data management:

When organizations decide not to use the old system any longer but start using a whole new system for their business processes, that’s referred to as new implementation. As the data models, architectures and modules are different between AFS and S/4 systems, AFS to S/4 Fashion migration can only be done as a new implementation.

Data Archiving for Historical Data: 

Master data and open transactional data are migrated to S/4 for business continuity through the S/4 migration cockpit. This means that historical data needs to be stored separately for compliance and audit purposes and their future references. This data needs to be managed optimally to reduce cost and make it accessible at the right time. (View Data Tiering from Applexus)

Complexity for Customized Processes:

Customized data and organizational data will not be migrated through the cockpit and it needs to be set up in S/4 for mapping. AFS stores Article data in a grid structure with one base and multiple variants based on the color, size, etc. of the base product whereas at S/4, each base and variant data are stored as a separate product with associated attributes. Custom processes built on SAP AFS, developed through custom tables need to be migrated separately in S/4. Removing this custom code is an opportunity to standardize the processes in S/4, but on the other hand adds to the complexity in mapping the data from source to target system, given the difference in data models.

Our client had custom operations and customized coding in AFS to run their day-to-day businesses. This had to be standardized in the target system (S/4) and that added to the complexity. Also, they had to achieve a quick cutover while having a smooth migration to the new system, for the very nature of the business they were in.

Seamless transition from AFS to S/4

Applexus understood the challenges and resolved them by focusing on three core areas:

Business requirements of the data:

Custom developments were built to serve a purpose. Our deep domain expertise in the Retail industry helped us understand the usage of these customs. This enabled us to map the data accurately between two systems. We quickly identified 19 business objects and prepared them for migration through our pre-built solution.

Timeline of the project:

Such complicated migration with customized processes often tends to overrun schedule. Our pre-built solution with re-defined BODS jobs helped us stay on schedule and focus our efforts on the customization that was required. We also addressed data quality issues before migration to ensure advanced analytics capabilities of S/4 to be leveraged in the future.

Business validations:

Multiple mockloads and business validation were also our key focus to ensure that the data migrated is validated with the users. Keeping in mind the complexities of the customized data grids, this validation also ensured the correct mapping of the data in the target system.