Choosing and Sequencing an S/4HANA SD Migration Approach: New Implementation vs System Conversion vs Selective Data Transition
Learn how SD-relevant decisions differ across the three main S/4HANA migration approaches, what to validate during each, and how integration and cutover risks show up specifically in sales processes.
Explanation
Once an organization has decided to move to S/4HANA, the next major architectural decision is the migration approach: new implementation (greenfield), system conversion (brownfield), or selective data transition (a hybrid that migrates selected data/objects rather than everything or nothing). Each approach has direct consequences for SD design, testing effort, and cutover risk, and a consultant needs to be able to reason about these trade-offs rather than treat migration as a purely technical/basis exercise. New implementation means building S/4HANA SD configuration largely from scratch, informed by current process documentation, and optionally using SAP-delivered best-practice scope content as a starting point (particularly relevant for public cloud, where scope items and predefined process variants are central to how SD is configured). The SD-specific implication is that legacy customizations (custom pricing procedures, custom output logic, non-standard document types) are not automatically carried over; each must be deliberately assessed and rebuilt if still needed. This approach suits organizations wanting to simplify heavily customized SD landscapes, or those moving to public cloud where classic customizing depth is restricted anyway. System conversion means technically converting an existing ECC system (including its SD configuration, custom code, and data) into S/4HANA. The SD-specific implication is that existing pricing procedures, document types, copy control, and output configuration generally carry forward, but must be checked against data model simplification changes; for example, code that reads from tables affected by simplification, or relies on behavior that changed with business partner unification, needs review during the technical and functional test phases. This approach is the common path for on-premise and private cloud customers who have significant custom SD logic they want to preserve. Selective data transition sits between these: it allows migrating selected organizational units, company codes, or historical data into a new S/4HANA system without a full greenfield rebuild or a full brownfield conversion of the entire landscape. For SD, this can mean, for example, bringing open sales documents and master data for specific sales areas into the new system while leaving fully closed/historical documents in a legacy archive or read-only system. This requires careful design of what 'open' vs 'closed' means for sales documents (open orders, deliveries, billing not yet completed) and close coordination with FI on open receivables tied to those documents. Across all three approaches, SD-specific validation activities include: reconciling pricing conditions and condition records post-migration, verifying copy control behavior between order-delivery-billing still functions as designed, confirming credit management integration behaves correctly (especially if moving from classic credit management to the S/4HANA credit management approach, which is a materially different architecture and should be treated as its own design decision, not assumed to be a direct carryover), and validating output determination end to end including any interfaces to EDI or external logistics providers. Cutover for SD typically requires careful sequencing: master data (customers via business partner, pricing conditions, output conditions) before open transactional documents, and open transactional documents before go-live cutoff, with a clearly communicated freeze period for sales order creation in the legacy system. Decisions about which open documents get migrated vs completed in the legacy system before cutover materially affect customer service continuity and must be agreed with business stakeholders, not just IT.
Real project scenario
A distribution company on ECC with private cloud target decides on system conversion because they have extensive custom pricing routines tied to rebate agreements they are not ready to redesign. During technical testing, the team discovers a custom report that directly queried a classic aggregated billing table for management reporting; it required rework to use the simplified data model correctly. Separately, the credit management team realizes their classic credit management setup needs to be redesigned under the S/4HANA credit management architecture, which becomes its own workstream rather than an automatic conversion outcome. Both findings were only surfaced because the team ran structured SD-specific validation rather than relying purely on the generic technical conversion checklist.
Common mistakes
• Assuming system conversion automatically preserves all custom SD behavior without functional retesting of pricing, copy control, and output. • Assuming classic credit management configuration converts identically to S/4HANA credit management without a dedicated design review. • Failing to define a clear cutover rule for open sales orders/deliveries/billing documents, causing confusion about which system is authoritative during go-live weekend. • Choosing new implementation for public cloud scope items without validating that the client's actual pricing and document flow needs fit within available scope item variants. • Treating selective data transition as simply 'a smaller version of system conversion' without designing explicit open-vs-closed document criteria agreed with business and finance.
Best practices
• Choose the migration approach based on how much SD customization must be preserved versus how much process simplification the business wants, not purely on technical convenience. • Treat S/4HANA credit management as a distinct design decision in any migration approach, never an automatic carryover assumption. • Build an SD-specific test plan covering pricing, copy control, output determination, and credit checks regardless of migration approach chosen. • For selective data transition, get explicit written agreement from sales and finance stakeholders on the open-vs-closed document cutoff rules before technical execution begins. • Validate public cloud scope item fit against actual customer pricing and document flow requirements before committing to a new implementation approach in that deployment model.
Interview angle
Be ready to compare new implementation, system conversion, and selective data transition specifically from an SD lens: what carries over automatically, what must be rebuilt, and what new architecture decisions (like credit management) are triggered regardless of approach. Interviewers value candidates who can explain trade-offs rather than just naming the three approaches.