Selecting and Implementing a Data Migration Approach: Conversion, New Implementation, and Selective Data Transition
How to choose between system conversion, new implementation, and selective data transition for an S/4HANA move, and what the technical execution of each approach actually involves.
Explanation
Choosing a migration approach is the single decision that shapes almost every downstream architecture choice: infrastructure sizing, custom code strategy, cutover duration, and business risk. There are three broad approaches recognized in S/4HANA transformation programs, and an architect must be able to justify the choice with concrete criteria rather than defaulting to whichever the implementation partner prefers. System conversion (technical conversion of an existing ECC system, historically executed with tools such as the Software Update Manager together with Database Migration Option when moving to SAP HANA as the database) preserves existing configuration, historical data, and custom code as-is, then transforms the system in place. This is attractive when the customer's core processes are healthy, custom code volume is manageable, and the business wants to avoid re-implementing configuration. The trade-off is that legacy complexity, unused customizations, and technical debt come along for the ride unless explicitly remediated before or during conversion. New implementation means standing up a fresh S/4HANA system and selectively migrating master data and, where required, historical transactional data using data migration tooling (for example SAP's predefined migration content used with migration cockpit-style tools, or custom ETL for complex objects). This approach is appropriate when the current system carries excessive customization, when a business wants to adopt more standard processes as part of the move, or when multiple legacy systems are being consolidated into one target. It costs more in re-configuration and testing effort but yields a cleaner starting point. Selective data transition sits between the two: it migrates a defined scope of historical data and configuration into a new or converted system without carrying forward the entire technical history, often used when only part of an organization (a company code, a business unit) needs to move, or when the business wants a clean core but still needs multi-year transactional history for reporting or legal retention. It typically requires specialized tooling and services beyond standard conversion or migration cockpit capabilities, and scope must be tightly defined because partial data transitions create reconciliation complexity. As an architect, the decision matrix should weigh: volume and quality of custom code, number of source systems being consolidated, appetite for process re-design versus continuity, data retention and legal requirements, downtime tolerance, and target deployment (on-premise/private cloud allows deeper technical conversion options; public cloud editions do not support technical conversion at all and effectively force a new-implementation-style data migration using cloud-appropriate tools). Runtime and execution flow generally follows: assess (custom code and data quality analysis), prepare (remediate blocking custom code, cleanse master data), realize (execute conversion or load), and validate (reconcile balances, run parallel or shadow testing). For conversions, this runs largely in the existing system with downtime windows for the technical switch. For new implementations, data loads run against a target system in parallel with the legacy system still live, which reduces cutover risk but requires careful synchronization of transactional cutoff dates. Troubleshooting commonly centers on data volume causing load failures or unacceptable runtime, mapping errors between legacy and target data structures, and reconciliation mismatches between source ledgers and migrated balances. Production support after go-live must retain migration logs and mapping documentation because late-discovered data issues (a mismatched vendor open item, for example) require tracing back through the exact transformation rule that produced it.
Real project scenario
A retail group with three legacy ECC systems (acquired through mergers) needed to consolidate into a single S/4HANA private cloud instance. A pure technical conversion was impossible because there were three source systems, so the architecture team selected new implementation with a phased selective data transition: two years of open items and twelve months of summarized historical postings were migrated per legacy system, while older data was archived and left queryable through a reporting-only legacy shell. This reduced go-live data volume by roughly 60 percent compared to a full historical carryover, which shortened mock cutover runs significantly.
Common mistakes
• Choosing system conversion primarily to save migration effort without assessing whether custom code volume makes the conversion technically and financially worse than a clean implementation • Underestimating selective data transition complexity by treating it as a lighter version of new implementation rather than a specialized reconciliation-heavy effort • Assuming public cloud editions support the same technical conversion path as on-premise or private cloud, leading to an infeasible plan late in design • Failing to define a clear data cutoff date and communicate it to business users, causing transactions to be entered in both legacy and target systems during transition • Not preserving detailed mapping and transformation documentation, making post-go-live data discrepancies very slow to trace
Best practices
• Run a formal custom code and data quality assessment before committing to an approach, not after • Match the approach to deployment target constraints, since public cloud editions do not support technical conversion • Define scope and cutoff dates explicitly for selective data transitions and get written business sign-off • Keep migration mapping and transformation logic documented and versioned for post-go-live traceability • Plan at least one full mock data load cycle before the production cutover, timed to reflect true production data volume
Interview angle
Interviewers assess whether a candidate can justify a migration approach using business and technical criteria rather than reciting tool names. Be ready to explain how custom code volume, source system count, data retention needs, and target deployment model (on-premise versus public cloud) each independently push the decision toward conversion, new implementation, or selective transition, and how the choice affects downtime and reconciliation effort.