Migration route

    Salesforce→SAP S/4HANA

    Salesforce to SAP S/4HANA Data Migration

    Migrate accounts, contacts, customer master from Salesforce to SAP S/4HANA using a controlled process for extraction, mapping, transformation, validation, loading and reconciliation.

    Discuss Your MigrationAll Migration Routes

    Migration overview

    Moving Salesforce data into an SAP estate is usually not a like-for-like CRM replacement. In practice it splits into two different jobs: customer and contact master data landing in S/4HANA as Business Partners, and sales process data landing in SAP's own CRM successor.

    Naming which of those is in scope is the first decision, because they have different targets, different validation and different owners.

    Typical data scope

    Scope is agreed in discovery. On this route it usually covers:

    Accounts

    Domain in scope for a typical Salesforce to SAP S/4HANA programme.

    Contacts

    Domain in scope for a typical Salesforce to SAP S/4HANA programme.

    Customer master

    Domain in scope for a typical Salesforce to SAP S/4HANA programme.

    Opportunities

    Domain in scope for a typical Salesforce to SAP S/4HANA programme.

    Migration architecture

    One controlled pipeline, run as repeatable cycles.

    Salesforce→DataMove→Transformation & validation→SAP S/4HANA→DataVault reconciliation→DataLens

    Extracting from Salesforce

    What the source platform makes available, and the constraints that shape the extraction design.

    15 vs 18 character record IdsSalesforce exposes a 15-character case-sensitive Id and an 18-character case-safe version of the same key. Mixing them, or letting a process change the case of the 15-character form, collapses distinct records onto each other. Extracts standardise on the 18-character Id.
    Bulk API 2.0 and SOQLBulk API handles volume; SOQL defines what is selected, including relationship traversal. Governor limits and batch behaviour shape how a large extract is staged.
    Lookup vs master-detailThe two relationship types behave differently on deletion and ownership and do not map to one target construct, so each is resolved explicitly rather than treated as a generic foreign key.
    RecordType drives validityRecordType decides which picklist values and layouts apply. A value valid under one RecordType is rejected under another, so RecordType is part of the mapping key, not an attribute beside it.
    Formula and rollup fieldsThese are calculated, not stored. They must be recreated in the target rather than migrated, or the target inherits frozen numbers that stop updating.
    Files, attachments and notesContent lives in its own objects with its own relationships. Carrying the parent record without them loses the evidence trail sales and service teams rely on.

    Source-to-target mapping

    A mapping workbook carries every field in scope from its Salesforce source through its transformation rule to the SAP S/4HANA target object and field. It is reviewed and approved with the business before the production migration, and applied identically in every cycle so a decision made once is not re-made under cutover pressure.

    Transformation challenges on this route

    The differences between Salesforce and SAP S/4HANA that create most of the work.

    Business Partner is the target model

    Salesforce accounts and contacts become Business Partners with roles, which merges populations Salesforce kept separate and exposes duplicates.

    Check-table validation is strict

    SAP rejects codes not present in its configuration outright, so country, region, industry and classification values are crosswalked and proven before load.

    Sales pipeline has no S/4HANA home

    Opportunities and forecasting do not belong in the ERP. If they are in scope, the target is SAP's CRM product and that is a separate migration with its own design.

    Number ranges and external keys

    Whether the Salesforce Id survives as an external reference is decided per object before mapping.

    Formula and rollup fields

    Calculated in Salesforce, so they are recreated in the target rather than migrated as frozen values.

    How SAP S/4HANA accepts the data

    Load order is part of the design, not an implementation detail.

    1. 1Settle the conversion approach firstBrownfield system conversion, greenfield reimplementation, or selective data transition. This determines the entire data scope, so it is decided before any mapping work begins.
    2. 2Business Partner conversion is mandatoryCustomers and vendors must arrive as Business Partners through Customer/Vendor Integration. This is where most conversions find their master-data problems: duplicate parties, number-range collisions between customer and vendor ranges, and records never clean enough to merge.
    3. 3Load through the Migration CockpitPredefined migration objects and templates cover the standard object set, with staging tables for higher volumes. Custom objects need their own migration object built.
    4. 4Enterprise structure, then masters, then transactionsThe same dependency order as ECC, against a target model where several structures have changed shape.
    5. 5Respect the changed modelAggregate and index tables are gone, material number field length is extended, and inventory aggregates are derived rather than stored. Interfaces and custom code that assumed the old shapes need finding before cutover, not after.
    6. 6Reconcile against the Universal JournalFinancial reconciliation is built against ACDOCA rather than the ECC structures, so existing reconciliation logic is rebuilt rather than reused.

    Business Partner conversion is the item that most often surprises a programme. It is mandatory, it exposes every historic duplicate between the customer and vendor masters, and it cannot be deferred past cutover — so master data is cleansed before conversion, not after.

    Validation and reconciliation

    Validation before load

    Mandatory fields, referential integrity, format checks, business-rule validation and duplicate detection run on the prepared data, so problems surface as reportable exceptions rather than as failed loads in SAP S/4HANA.

    Reconciliation after load

    Source counts, transformed counts, rejected records and target counts, with control totals where the data supports them. Every discrepancy is categorised so the migration is approved on evidence rather than assertion.

    Migration cycles

    The pipeline is run end to end more than once before anything touches production. A typical structure is a first rehearsal that surfaces the bulk of mapping and data-quality corrections, a second that applies them and demonstrates production readiness, and the production cutover itself. How many cycles a programme needs depends on data quality and scope, which is established during discovery.

    1. 1Mock / PPR 1First full extract, transform, load, reconcile and exception analysis. Expect the largest correction list here.
    2. 2Mock / PPR 2Corrections applied, re-extract, re-run. Intended to closely replicate the production migration.
    3. 3Production cutoverFinal extract, data freeze, load, reconciliation, business validation and sign-off.

    Common risks on this route

    Scope conflated

    Treating master data and pipeline as one migration produces a design that fits neither.

    Duplicate parties on Business Partner merge

    Cleanse before conversion, not after.

    Strict validation discovered late

    SAP's check tables reject more than teams from CRM backgrounds expect.

    How Syntra ETL supports this route

    DataMove

    Extraction, mapping, transformation and load preparation for SAP S/4HANA.

    Explore DataMove →

    DataVault

    Source-to-target reconciliation, migration lineage and audit evidence for every cycle.

    Explore DataVault →

    DataLens

    Migration status, data quality and exception visibility across cycles.

    Explore DataLens →

    Related enterprise migration experience

    We have not published a case study for this exact route. These delivered projects are the closest relevant experience.

    Salesforce→Oracle Fusion CX

    Salesforce to Oracle Fusion CX data migration

    Accounts, Contacts, Leads, Opportunities

    Case study available →    SAP ECC→SAP S/4HANA

    SAP ECC to SAP S/4HANA data migration

    Financials, Controlling, Master data, Logistics

    Case study available →

    Related migration routes

    Salesforce→Oracle Fusion CX

    Salesforce to Oracle Fusion CX data migration

    Accounts, Contacts, Leads, Opportunities

    Case study available →    Salesforce→Microsoft Dynamics 365

    Salesforce to Microsoft Dynamics 365 data migration

    Accounts, Contacts, Leads, Opportunities

    View route →    SAP CRM→Salesforce

    SAP CRM to Salesforce data migration

    Business Partners, Accounts, Contacts, Opportunities

    View route →    SAP ECC→SAP S/4HANA

    SAP ECC to SAP S/4HANA data migration

    Financials, Controlling, Master data, Logistics

    Case study available →

    Planning this migration?

    Tell us your source system, target platform, modules, data volumes and timeline. We can discuss the closest relevant migration experience and the recommended approach.

    Discuss Your MigrationSee Delivered Projects