In many programs, S/4HANA joins the landscape later than planned. That delay changes how you should set up SAP Sales Cloud v2 today. Instead of first building a standalone CRM and then retrofitting it to S/4. You rather design Sales Cloud v2 from the start with S/4 as the master. This approach ensures seamless integration and avoids rework later. The following recommendations outline a distinctive, low-regret approach that keeps rework minimal when S/4 finally arrives.
Start with S/4 in mind
Model Sales Cloud v2 Sales Units to mirror S/4’s Sales Area (Sales Organization, Distribution Channel, Division). Do not create a CRM-only hierarchy you will rewire later. Assign the future S/4 keys as External IDs on the Sales Cloud org elements immediately. When S/4 comes online, the organizational alignment already exists; you switch on integration rather than rename and remap structures.
Treat S/4 as the future golden record
Use Sales Cloud v2 during the transition, but treat Accounts, Contacts, and Products as if S/4 will own them soon. For each business partner, store the future S/4 BP number as the External ID. And for each product, use the future material number the same way. Keep custom fields minimal—only add them if there’s a clear S/4 target or an agreed extension plan. This discipline lets Sales Cloud v2 stitch records to S/4 automatically once replication starts, without renumbering or cleanup scripts.
The practical steps are as follows:
- Draft your S/4 enterprise structure (Sales Org/DC/Division, Offices/Groups) now; mirror it one-to-one in Sales Cloud v2 Org Units.
- In Sales Cloud v2, enable ID mapping and maintain the future S/4 keys as External IDs for each Org Unit and Allowed Sales Areas.
Accounts/Contacts
- Use Sales Cloud v2 for UX and pipeline now, but reserve S/4 BP numbers/logic for later. If you already assign numbers, align the format/length to S/4’s number range and store that value as External ID.
- Keep KUT (key user) fields lean; prefer fields that have obvious targets in S/4 (BP roles, industry codes, country/region, tax numbers). If custom fields are unavoidable, document mappings early for integration flows. (Sales Cloud v2 → S/4 BP replication uses delivered content once you connect.)
Products
- If you must sell in standalone mode, create products with the intended S/4 material number as the External ID; avoid bespoke product hierarchies that won’t exist in S/4. Later, S/4→Sales Cloud product replication and ID mapping will line up cleanly.
Lock IDs and code systems before you integrate
Decide early that S/4 will lead number ranges and formats, then respect those constraints inside Sales Cloud v2. Enable External ID Mapping everywhere and avoid exposing technical UUIDs to users or downstream files. This lets you keep references stable across the cutover. Standardize ISO domains like country, currency, and units of measure. Keep one shared code-list mapping for values that differ between systems (e.g., industry codes or product groups), and version it with the application so updates stay consistent across imports and integrations.
Code lists & domains
- Activate Code List Mapping/ID mapping where values will differ (e.g., industry code, product groups). If values are 1:1, use “pass-through” rules; if not, pre-map now to avoid a scramble during go-live. An interesting discussion around that topic was kicked off some weeks ago on Reddit.
- Normalize ISO codes (country, currency, UoM) to S/4 from the start.
Integration pattern (when ready)
- Standard guides cover BP and Product replication from S/4 → Sales Cloud v2 via SAP Integration Suite (CPI)and DRF/DRFOUT for initial loads; Sales Orders can be simulated/created in S/4 once connected. For more details on that see the SAP Learning Journey on that topic.
- If you have multiple consuming apps, consider SAP Master Data Integration (MDI) as a hub using One Domain Model to distribute BP/Product master—this reduces point-to-point mappings when S/4 arrives.
Rehearse the cutover well before go-live
Run a dry integration in a sandbox long before the production cutover. Replicate a small set of business partners and materials through Integration Suite (CPI) and DRF, and verify that Sales Cloud v2 recognizes the objects by External IDs, applies the correct sales-area visibility, and populates pricing prerequisites where needed. Capture and fix mismatches (for example, code lists or tax identifiers) while there is no pressure. When the real cutover comes, perform the initial load from S/4, let deltas flow via CPI, and keep Sales Cloud v2 as the front-office UX throughout. If multiple consumers need master data, consider SAP Master Data Integration (MDI) to reduce point-to-point mappings.
We further recommend to document a short runbook and hold teams to it. The steps are as follows:
- Freeze structure early: lock the Sales Cloud v2 Org Units to match the final S/4 design. Fill External IDs with the target S/4 keys.
- Run a dry integration: stand up a sandbox S/4 or a stub through MDI/CPI. Push a small set of BP/Materials and confirm ID mapping behavior and sales-area authorization in Sales Cloud v2.
- Initial load from S/4: once S/4 is live, replicate org structures, BP, and products. Let External ID Mapping stitch records to what you created during standalone. (consult SAP Integration Guide for SAP S/4HANA Cloud Public Edition)
- Flip the master: move new-record creation to S/4 (or MDG), and keep Sales Cloud v2 for front-office processes. You should run deltas via CPI. (see SAP Learning Journey on the integration between both systems)
Avoid the common pitfalls
Common pitfalls we recommend NOT to do:
- invent temporary org units “just for CRM.”
- leak internal UUIDs into spreadsheets or integrations; always expose External ID + Name.
- add custom fields with no S/4 destination; either drop them or design the S/4 extension first and mirror it to Sales Cloud v2. Choose long-term alignment over short-term convenience every time.
Keep small, reusable assets ready
Maintain three lightweight artifacts in version control and reuse them across environments:
- An External ID import template (CSV) for accounts, contacts, and products that enforces the target S/4 keys.
- A code-list mapping file (JSON/CSV) that defines one source of truth for divergent domains.
- An org-unit registry that lists Sales Units and their SalesOrg/DistChannel/Division keys.
These simple files prevent drift, accelerate test cycles, and reduce last-minute surprises.
Run an operating model that survives delays
Let Sales Cloud v2 own the front-office experience—pipeline, activities, quoting—while you prepare S/4 to own master data and product enablement when it’s ready. Keep your integration runbook current, including owners, retry procedures, and the locations of number ranges and mappings. This clarity keeps the team productive during the wait and makes the eventual cutover routine.
Summary: Recommendation to program leads
If your roadmap expects S/4 to arrive later, build Sales Cloud v2 as if S/4 were already in charge. Mirror S/4 sales areas from the start, enable External ID Mapping in every relevant object, normalize code lists, and rehearse the integration before you need it. When S/4 finally enters the landscape, you will connect CPI or MDI, run the initial load, flip creation to S/4, and keep users working—without expensive remodels or emergency cleanups.
