Versions Compared

Old Version 8

changes.mady.by.user NARAHARI-ext, Bhargavi

Saved on

compared with

New Version 40

changes.mady.by.user HUYNH-ext, Danh

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Status

Page Status

Owner

NARAHARI-ext, Bhargavi 

Stakeholders

Purpose

This document outlines the SyWay Program approach to data migration and readiness to move to new business processes as part of Release 2. It establishes an operational framework to ensure data is clean, reliable, structured and available at go-live.

The objectives are:

  • To plan, govern and control data migration activities from legacy systems to Ariba and Icertis applications.

  • To ensure business engagement and ownership in all data quality and validation activities.

  • establish a forward-looking data strategy in Release 2 that minimizes the volume of data migration required during Release 4, thereby reducing risk, effort, and rework in later phases of the program.

  • To identify and define the data objects and migration requirements from ECC and other third-party systems to Ariba, Keelvar, and Icertis as part of Release 2To meet global regulatory, operational and integration requirements with third-party systems.


Background

This document outlines the data migration and cleansing approach for Release 2, which focuses on the implementation of the Source to Contract (S2C) process as part of the broader program roadmap. Release 2 is an intermediate deployment that introduces standardised procurement processes and integrates with existing ECC systems and third-party applications such as Convergence.

The primary objective of this release is to establish foundational S2C capabilities that can be reused and scaled during subsequent releases, particularly Release 4 (R4), which will involve a broader S/4HANA transformation. As such, the data migration strategy for Release 2 is designed with reusability and future scalability in mind.

Due to the continued reliance on legacy ECC systems in this phase, there are limitations in the extent of data cleansing that can be performed. Existing data in ECC will be migrated largely in its current state, with only targeted validations and enrichment applied where feasible. Cleansing activities will be focused on data sets required for the new S2C processes and integrations, ensuring functional readiness without major disruption to upstream or downstream systems.


Data

Migration

Scope

The scope of data migration encompasses all master dataencompasses all master data, open transactional data and selected historical records required to ensure business continuity, legal compliance and readiness at the point of cutover and afterfor Release 2. Data will be migrated from multiple SAP ECC source systems and legacy third-party applications into a Standardized SyWay environment.

Data Sources

Data will be extract data from a range of legacy systems that currently support Syensqo’s global operations. These sources span SAP and non-SAP applications and applications and include structured and semi-structured data repositories. The source systems are segmented across regions, functions, and business units and must be accessed in a secure, controlled manner to support data profiling, transformation, and validation activities. 

Primary Data Sources include:

  • SAP ECC systems – multiple instances

  • Convergence

  • Contract repositories (other than convergence) ./ Local drives


Data Migration Process

For Release 2, the data migration process supports the enablement of Source to Contract (S2C) functionality within SAP Ariba, with downstream integration to Icertis, which acts as a slave system consuming master data from Ariba. Unlike traditional ERP implementations, most relevant data for S2C is treated as configuration within Ariba, requiring a data-driven approach to setup rather than transactional migration.

The data team’s primary responsibility is to populate Data tables / Ariba upload templates, which define the system’s configuration and reference data. These templates serve as the foundation for both Ariba and Icertis, as Icertis relies on Ariba to provide key master data objects such as suppliers, categories, and organizational structures.

The process follows these key steps:

StepActivityOwned By
Template
Finalization
FinalisationStandard Ariba/Icertis templates for key data objects (e.g., suppliers, commodity codes, sourcing templates, approval flows)
are reviewed and finalized in collaboration with Ariba functional leads and business stakeholders.
Functional Team
Data CollectionSource data is gathered from existing ECC systems, third-party applications (e.g., Convergence)
, and available documentation or spreadsheets. Given the limitations in cleansing capabilities within ECC, extracted data is used largely in its existing form, with targeted validations where necessary.
etc.Data Team / Contract Migration team
Template Population
The data migration team populates the Ariba upload templates, applying data mapping and transformation logic to align source data with Ariba's structure. Particular care is taken to ensure consistency in the master data that will be shared downstream with Icertis.
Source data is provided to the function team for populating the templatesFunctional Team / Data team / Contract Migration team
Validation and Review
Completed templates are reviewed with process owners and Ariba functional teams to verify data completeness, accuracy, and alignment with configured business processes. Templates are refined through multiple review cycles.Upload to Ariba and Functional Testing
Validation of the values with BusinessFunctional team
Upload TemplatesValidated templates are uploaded into Ariba/ICertis using its import tools
. Functional testing in the test environment verifies that the configuration behaves as expected, and that master data is correctly consumed by Icertis where applicable.
Functional Team
Issue Resolution and Final Migration
Any issues identified during testing are addressed in coordination with functional and integration teams. Final templates are prepared for production upload during cutover activities.



Data Objects in Scope

Following are the data objects that are in scope for Release 2

Data ObjectCategoryHow is it loaded in AribaHow is it loaded in IcertisHow is it loaded in Keelvar
Company CodeEnterprise StructureInterface
Replication from Ariba

Manually Upload

N/A

Purchasing OrganizationEnterprise StructureInterface
Replication from Ariba

Manually Upload

N/A
Purchasing GroupsEnterprise StructureInterface
Replication from Ariba

Manually Upload

N/A
PlantEnterprise StructureInterface
Replication from Ariba

N/A

N/A

Suppliers

Master Data

Interface from ECC

/ Convergence

Replication from Ariba

Replication from Ariba

BiddersMaster DataManually created in Ariba
Interface
Replication from
ECC / Convergence
AribaReplication from Ariba
MaterialsMaster DataNot RequiredN/A
Material Groups / Commodity CodesMaster DataInterface
N/A
Material Groups Master Data

Interface

(L3 - used in Line Item Level)

Manually Upload

(L3 - used in Line Item Level)

N/A
Commodity Codes Master Data

Manually Upload

(L1/L2/L3 - used in Header Field)

Manually Upload

(L1/L2/L3 - used in Header Field)

Manually Upload

(L3 - used in Header Field)

Replication from Ariba

UOM

Master Data

Upload

N/A

N/A

Replication from Ariba

Payment Terms

Master Data

Interface

Replication from Ariba

Manually Upload

N/A

IncotermsMaster DataInterface
Replication from Ariba

Manually Upload

N/A
CurrencyMaster DataUpload
Replication from Ariba

Manually Upload

N/A
Item CategoriesMaster DataInterface

N/A

N/A
Users (Including Jobs, Roles and org structure)*Master DataInterface from IAGInterface from IAGReplication from Ariba
Legal Contracts Transactional DataN/AUploadN/A
Exchange RatesTransactional DataInterface

Interface

N/A

*User interfaced from IAG. Roles configured in Ariba and Icertis 

Data approach for R2 and R4

The data strategy for the Source to Contract (S2C) implementation spans across Release 2 and Release 4, with a clear distinction in how data is handled across both Ariba and Icertis.

Release 2 Data Approach

In Release 2, the focus is on enabling Ariba Guided Sourcing / Contracts using a targeted data set derived from existing ECC and third-party systems. This data is used to configure Ariba / Icertis via interfaces / upload templates and to support sourcing and contracting processes. Key characteristics of the Release 2 approach include:

Data Entry in Ariba: Configuration and master data required for sourcing are loaded into
Ariba
using predefined templates.Icertis Consumption:

  • One-Time Use of Data: The data supports sourcing events initiated during Release 2. Once sourcing documents (e.g., RFPs, auctions) are completed, they are not reopened or modified.

    • Icertis
    consumes master data from Ariba, aligning with the Release 2 data set to support contract lifecycle management.

    Release 4 Data Approach in Ariba Sourcing and 

    The Source to Contract (S2C) data strategy spans multiple releases, transitioning from a manually managed data load in Release 2 to a fully integrated and governed master data model in Release 4. The approach differs by system, depending on its role in the S2C landscape.
    This section outlines the data approach for Ariba, Icertis, and
    Keelvar
    across both releases.

    Release 2

    Ariba
    Data Source & Load Method:

    • Master and reference data required for Ariba Guided Sourcing (e.g., suppliers, commodity codes, organizational units) are collected from ECC and third-party systems. Data is loaded via structured Ariba upload templates.

    Cleansing & Standardization:
    Due to limitations in ECC, only minimal
    Icertis
    Data Consumption Model:
    Icertis consumes master

    • No data cleansing except Payment Terms is performed. Data is validated where feasible but largely migrated in its existing form.

  • Document Handling:
    Sourcing documents initiated in Release 2 are not reopened or updated after completion. Therefore, no retrofitting of documents is needed.

    • Consumes supplier and bidder master data from Ariba based on the Release 2 configuration

    . It is not yet integrated directly with S/4 or MDM systems.Configuration Approach:
    Data

    • using standard integration. 

    • Any Icertis specific data is manually configured to align with Ariba/ECC to ensure consistency in contract metadata

    .Retrofit Status:
    No retrofit is performed in Release 2. Contracts created during this phase remain linked to the original data set

    • .

    Keelvar

    Data Role:

    • Keelvar is used for strategic sourcing and optimization and feeds off master/transactional data in Ariba based on each event.

  • Master Data Handling:
    Keelvar does not store master data locally. It dynamically pulls data from Ariba for sourcing events.

  • Action Required:
    No data load or configuration activity is required in Release 2 for Keelvar.

    •  Master data of Supplier, Commodity Code (L3) and GBU are stored in Keelvar.

    Release 4 Data Approach 

    The Source to Contract (S2C) data strategy spans multiple releases, transitioning from a manually managed data load in Release 2 to a fully integrated and governed master data model in Release 4. The approach differs by system, depending on its role in the S2C landscape.

    This section outlines the data approach for Ariba, Icertis, and Keelvar across both releases.

    AribaIcertisKeelvar
    • Ariba is

    Release 4

    Ariba
    Data Source & Integration:
    Ariba is now
    • integrated with S/4HANA and Master Data Management (MDM) systems. Master data is replicated directly from S/4, replacing the manually loaded Release 2 data.

    • Data

    Quality & Governance:
    Data

    • is centrally cleansed, validated, and governed before replication, ensuring higher data quality and standardization across the S2C process.

    Document Handling:
    As with Release 2, completed

    • Completed/Inflight sourcing documents are not retrofitted. New events will automatically use the integrated S/4-based master data.

    Icertis
    Alignment with S/4 Master Data:
    • To stay in sync with the new S/4-driven master data, Icertis requires a retrofit of existing contract data.
    Retrofit Execution:
    • Leveraging Icertis's find-and-replace capability, master data fields (e.g., supplier names, commodity groups)
    can
    • will be updated to reflect the S/4 data model.

  • Outcome:
    Contracts remain compliant and consistent with the new enterprise data standards post-R4.

    • Keelvar
    Data Role Remains the Same:
    Keelvar
    • continues to act as a consumer of Ariba data
    and does not persist any master data.

  • Impact of Integration:
    With Ariba now sourcing its master data from S/4, Keelvar will automatically consume the updated data without requiring any changes or data loads.

    • Action Required:
    • . 
    • No retrofit or data migration activity is required in Release 4 for Keelvar.
    System

    Following is the table of all the data objects and the approach in Release 2

    Approach

    and Release 4

    Approach
    AribaManual data load via templates
    Limited cleansing
    No document retrofit    		Master data integrated from S/4 and MDM
    Higher quality data
    No document retrofit
    IcertisConsumes Ariba-configured data
    No retrofit    		Retrofit required to align with S/4 master data
    Find-and-replace supported
    KeelvarPulls data from Ariba
    No data stored
    No action required    		Continues to consume data from Ariba
    Updated data from S/4 flows through
    No action required

    Assumptions

    The following assumptions have been made for the data migration approach and serve as the basis for planning, design and execution across all phases of the migration lifecycle.

  • Data ownership and cleansing accountability and responsibility is with the business, supported by the Data Team and functional leads.

  • Source systems will remain stable and accessible throughout all planned mock and cutover cycles.

  • Master data standards and Conversions functional specifications will be "checked in" ahead of each mock load and consistently applied across systems and regions.

  • Data Collection Templates (DCTs) are aligned to the target data model and generally do not require further structural transformation.

  • Mock migration timelines are non-negotiable rehearsal checkpoints to validate readiness.

  • Syniti Migrate will remain the primary platform for managing extraction, transformation, load and validation.

  • Custom load programs, where required, will be approved through the formal governance process and will follow the same validation and audit protocols as standard loads.

  • Security, access and privacy protocols are in place to ensure sensitive data is protected throughout the migration process.

    • Final load decisions will be made based on successful completion of technical validations and formal business approvals from designated data owners.

    .

    Data ObjectChange in R4R2 R4Pre-requisite
    Company Code

    Numbering 

    Scope

    		Existing company codes are replicated to Ariba and Icertis

    Ariba: The R2 company codes are inactivated, and the new company codes are made active

    Icertis: The R2 company codes are replaced with R4 company codes

    Mapping between R2 and R4 codes

    Purchasing OrganizationNumberingExisting Purchasing Org codes are replicated to Ariba and Icertis

    Ariba: The R2 POrgs are inactivated, and the new codes are made active

    Icertis: The R2 POrgs are replaced with R4 codes

    Mapping between R2 and R4 codes

    Purchasing Groups

    Numbering

    Scope

    		Existing Purchasing Groups codes are replicated to Ariba and Icertis

    Ariba: The R2 Pgroup are inactivated, and the new codes are made active

    Icertis: The R2 Pgroup are replaced with R4 codes

    Mapping between R2 and R4 codes

    Plant

    Numbering

    Scope

    		Existing plants are replicated to Ariba

    Ariba: The R2 plants are inactivated, and the new codes are made active

    		Mapping between R2 and R4 codes

    Suppliers

    Numbering

    Scope

    		Existing suppliers are replicated to Ariba, Icertis and Keelvar

    Ariba and Keelvar: The R2 suppliers are inactivated, and the new codes are made active

    Icertis: The R2 suppliers are replaced with R4 codes

    Mapping between R2 and R4 codes

    Bidders

    Numbering

    Scope

    Existing bidders are replicated to Ariba, Icertis and Keelvar

    Ariba and Keelvar: The R2 bidders are inactivated, and the new codes are made active

    Icertis: The R2 bidders are replaced with R4 codes

    Mapping between R2 and R4 codes

    Materials

    Numbering

    Scope

    Existing materials are replicated to Ariba and Icertis

    Ariba: The R2 materials are inactivated, and the new codes are made active

    Icertis: The R2 materials are replaced with R4 codes

    Mapping between R2 and R4 codes

    Material Groups 

    Numbering

    Scope

    Existing material groups are replicated to Ariba and Icertis

    Ariba: The R2 material groups  are inactivated, and the new codes are made active

    Icertis: The R2 material groups  are replaced with R4 codes

    Mapping between R2 and R4 codes

    Commodity Codes

    Numbering

    Scope

    Existing commodity codes are replicated to Ariba, Icertis (L1/L2/L3) and Keelvar (L3)

    Ariba and Keelvar: The R2 commodity codes are inactivated, and the new codes are made active

    Icertis: The R2 commodity codes are replaced with R4 codes

    Mapping between R2 and R4 codes

    UOM

    Scope

    Existing UOM are replicated to Ariba

    Ariba: The delta UOM for R2 are inactivated, and the new codes are made active

    Mapping between R2 and R4 codes

    Payment Terms

    Scope

    Old Payment terms are loaded and marked as inactive

    New Payment terms loaded

    No Action required

    N/A

    IncotermsScopeExisting incoterms are replicated to Ariba and Icertis

    Ariba: The delta incoterms are inactivated, and the new codes are made active

    Icertis: The R2 incoterm codes are replaced with R4 codes

    		N/A
    Currency NoneExisting currencies are replicated to Ariba and IcertisNo Action requiredN/A
    Item CategoriesNoneExisting Item Categories are replicated to AribaBased on lean services outcome, Lean Services needs to be added in the item categoriesN/A
    Users (Including Jobs, Roles and org structure)

    Numbering

    Scope

    		Existing users replicated based on their current Jobs and RolesUsers with their new Jobs and Roles are replicatedN/A
    Legal Contracts MetaDataNoneMeta Data determined in Release 2 is loadedNo Action RequiredN/A
    Legal Contract Templates (Clauses)NoneLegal contracts and clauses are loadedNo Action RequiredN/A
    Legal Contracts NoneLegal contracts and clauses are loadedNo Action RequiredN/A
    Exchange RatesNoneExchange Rates from ECC are loaded dailyNo Action RequiredN/A


    Legal Contract Migration Approach

    Following is the approach followed for the legal contract migration:

    1. Contract attributes are defined by the functional team
    2. Contracts and existing attributes are extracted from Convergence and other data sources by contract migration team
    3. Contracts are loaded on to Harvey to extract the contract metadata and relationships
    4. The contract metadata and relationships are validated - This step is performed only on selected critical contracts which are agreed with Business upfront
    5. The validated contracts are loaded into Icertis along with the metadata and attachment
    6. Any relevant Z-tables are updated with Icertis contract ID - They contain convergence ID previously

    Image Added


    Change log

    Change History
    limit10

    Workflow history

    Workflow Report
    parent@self
    hideheadertrue
    typeapprovals