For many organizations still running SAP ECC, the calendar has become the project plan. Mainstream maintenance for SAP Business Suite 7, including ERP 6.0, ends at the close of 2027. Extended maintenance is available from 2028 through 2030 at a higher fee, and SAP’s transition option offers a path to 2033 only for qualifying customers moving to a cloud subscription. With roughly a year left before the mainstream deadline, many S/4HANA programs are discovering that their critical path runs not through configuration or custom code but through data.
Decades of master data duplication, inconsistent customer and vendor records, open items nobody can explain and history nobody has archived all have to be dealt with before go-live. This playbook focuses on the data side of the move: choosing an approach with data in mind, cleansing and governance, the conversions S/4HANA requires, mock loads and reconciliation, and how to sequence the work when time is short.
What the Deadlines Actually Mean
It is worth being precise about the dates, because there is a lot of loose talk about “support ending.” Based on SAP’s published timelines as summarized by SAPinsider and The Register:
- End of 2027: mainstream maintenance for SAP Business Suite 7 and ERP 6.0 ends.
- 2028 to end of 2030: optional extended maintenance, priced at a premium of two percentage points on the maintenance basis.
- 2031 to end of 2033: the SAP ERP, private edition, transition option, a subscription rather than a maintenance extension. It requires moving to SAP ERP private edition on SAP HANA before the end of 2030 and has further eligibility conditions, including system size thresholds and a paired success plan. SAP has said it is intended for a small number of very large, complex customers.
In practice, extended maintenance buys time but not innovation, and the transition option is narrow and costly. For most organizations, the realistic objective is to complete the move, or at least the critical data work, within the next two to three years. Starting the data stream now is the single most effective way to protect that timeline.
Choosing an Approach with Data in Mind
The three classic approaches have very different data implications:
Brownfield (system conversion)
The existing ECC system is converted in place, retaining configuration, history and open items. Data effort concentrates on technical prerequisites and cleanup before conversion. The risk is that years of poor-quality data and unnecessary customizations simply move to the new system unless they are fixed as part of the project.
Greenfield (new implementation)
A new S/4HANA system is built around redesigned processes, and data is migrated selectively, typically master data, open items and opening balances. This is the best opportunity to clean data, but it requires a clear decision on how history will remain accessible, often through archiving or a separate reporting environment.
Selective data transition
Sometimes called bluefield, this approach moves selected data and configuration, for example specific company codes or a defined period of history. It suits consolidations, divestitures and phased rollouts, but mapping, dependency management and reconciliation become more complex with every additional source system or company code.
When choosing, weigh how much history the business genuinely needs online, how clean current data is, whether organizational structures are changing, and whether different business units need different timelines. Assessment tools such as SAP Readiness Check help identify simplification items and financial data issues, but their output must be interpreted by people who understand both the processes and the data.
In most S/4HANA programs the calendar is set by data, not by configuration. Start cleansing and reconciliation design on day one, whatever approach you choose.
The Data Workstreams That Decide the Timeline
Profiling and scoping
Begin by profiling master and transactional data across the landscape: duplicates, incomplete records, inconsistent formats, obsolete materials, inactive customers and vendors, and open items older than any reasonable business need. Decide explicitly what will be migrated, archived or discarded. Every record you do not migrate is one you do not have to cleanse, map, load and reconcile.
Business Partner and customer-vendor integration
S/4HANA uses the Business Partner as the central object for customers and vendors, so ECC customer and vendor master records must be synchronized into Business Partners through customer-vendor integration before or during conversion. This is one of the most data-intensive prerequisites, because it surfaces every inconsistency in addresses, tax numbers, bank details and account groups. Treat it as its own workstream with dedicated owners.
Finance data
Finance in S/4HANA consolidates line items into a single journal structure. Inconsistencies between ledgers, subledgers and asset accounting that ECC tolerated must be resolved, and open items reconciled, before conversion or migration. Finance consistency checks should run early and repeatedly, not only in the final mock.
Archiving and history
Archiving old documents reduces conversion runtimes, migration volume and target system size. Agree on retention requirements with legal and audit, archive aggressively within those limits, and design how users will access archived or legacy history after go-live.
Data governance
Cleansing without governance is temporary. Define data owners, quality rules, approval workflows and monitoring for the key master data domains, and enforce them before data enters the new system, so S/4HANA starts clean and stays clean.
A practical way to start is a data quality scorecard per domain, updated weekly, showing completeness, duplicates and rule violations for the records in migration scope. Owners see exactly where their data stands, cleansing effort can be prioritized by impact, and the steering committee gains an objective view of readiness long before the first mock load.
Tooling: From Migration Cockpit to Specialist Platforms
SAP’s standard tool for loading data into S/4HANA in new implementations is the SAP S/4HANA Migration Cockpit, which provides predefined migration objects and templates. It is well suited to straightforward loads. For complex landscapes with heavy transformation, multiple sources, large data quality remediation and governance requirements, many programs add specialist data migration platforms or a custom staging layer for profiling, cleansing, mapping and validation before data reaches the Migration Cockpit. Selective data transition typically relies on specialized SAP and partner tooling and services.
Whatever the tooling, insist on three capabilities: repeatable, scripted loads that can run many times; transparent mapping and transformation rules under version control; and automated reconciliation reports that business owners can read.
A Mock-Load and Reconciliation Playbook
Successful programs treat data migration as a series of rehearsals that steadily improve quality and predictability:
- Mock 1: technical proof. Load a subset of objects to validate mappings, templates and load sequence. Expect many errors; the goal is learning.
- Mock 2: full volume. Load all in-scope objects at production volume to measure runtimes and identify performance bottlenecks and data quality issues at scale.
- Mock 3: business validation. Business users validate migrated data in the target through realistic process tests: create orders, post invoices, run payments and close a period.
- Dress rehearsal. Execute the complete cutover plan, including freezes, extracts, loads, reconciliation and sign-offs, against the planned timeline.
- Production cutover. Run the same script, with the same checks, and go live only on agreed sign-offs.
Reconciliation should operate at several levels: record counts per object, financial totals such as open item balances, inventory values and asset values by company code, and sampled record-level comparisons for key master data. Each reconciliation needs a business owner who signs off, and an agreed tolerance where exact matching is not possible.
Track a small set of metrics across mocks to show whether the program is converging: load error rates per object, the number of open data defects by severity, runtime per object against the cutover window, and the number of reconciliations signed off without exceptions. Rising error rates or runtimes between mocks are early warnings that deserve attention before the next cycle, not after it. Publishing these metrics to the steering committee also turns data readiness from a vague concern into a managed, visible part of the program.
Sequencing the Work When Time Is Short
Many organizations are starting later than they would like. When the window is tight, sequence the data work so that the longest-running tasks begin immediately and do not wait for design decisions that can be made in parallel:
- Weeks 1 to 4: profile and scope. Profile master data quality, measure volumes, identify archiving candidates and run finance consistency checks. These activities are needed regardless of approach and inform the approach decision itself.
- Months 1 to 3: start cleansing at the source. Deduplicate and complete customer, vendor and material records in ECC, so the business benefits immediately and later loads are cleaner.
- Months 2 to 6: archive and prepare Business Partner conversion. Execute archiving within agreed retention rules and run customer-vendor integration in test environments to surface errors early.
- From month 4: build repeatable migration pipelines. Implement extraction, transformation, loading and reconciliation as scripted, version-controlled processes ready for the first mock.
- Final 6 to 9 months: mock cycles and cutover rehearsal. Run successive mocks with increasing scope and business participation, ending with a full dress rehearsal.
The exact durations depend on landscape size and data quality, but the principle holds: profiling, cleansing, archiving and Business Partner preparation have long lead times and few dependencies on the final design, so they should start first.
Where Automation and AI Help
Automation has a meaningful role in data migration, provided it is used for well-bounded tasks with human review. Machine learning and rule-based matching help identify duplicate customers, vendors and materials across countries and spelling variants. Language models can suggest mappings between legacy fields and target structures, draft transformation rules and explain undocumented custom tables, which speeds up analysis. Automated reconciliation compares counts and totals after every mock, freeing people to investigate differences rather than compute them.
What automation should not do is make final decisions on data ownership, retention or financial treatment. Merging two customer records, writing off an old open item or changing how an asset is valued are business decisions with audit consequences. Use automation to produce candidates and evidence, and keep approval with the accountable data owners.
A Worked Example: A Multi-Country Distributor
Consider a distributor running a single ECC system for operations in eight countries, with around fifteen years of history. It chooses a greenfield approach to harmonize processes, migrating open items, opening balances and three years of selected history, with older data archived and accessible through a reporting environment.
Profiling reveals large numbers of duplicate and inactive customer records, inconsistent tax numbers across countries and a long tail of obsolete materials. The program establishes a data office with owners for customer, vendor, material and finance data, sets quality rules, and cleanses in the source system ahead of migration so that the business continues operating on improved data in the meantime.
Business Partner mapping runs as a dedicated workstream. The first mock load exposes mapping gaps in bank details and address formats for two countries; these are fixed and the rules encoded. The full-volume mock shows that one large object exceeds the cutover window, so the team pre-loads static master data a week before cutover and loads only delta and open items during the final window. By the dress rehearsal, reconciliations for open item balances and inventory values match within agreed tolerances, and finance signs off. The project’s timeline was set by data readiness from start to finish, and treating it that way is what kept it on schedule.
Pitfalls and Conclusion
- Starting data work late. Cleansing and Business Partner conversion take months; leaving them until configuration is finished guarantees delay.
- Migrating everything. Every unnecessary record adds cost and risk. Archive or retire it.
- One-off scripts. Loads that cannot be repeated reliably make mock cycles meaningless.
- Technical reconciliation only. Record counts are not enough; finance and operations must validate business totals.
- Ignoring post-go-live governance. Without ownership and quality rules, data quality degrades within months.
The 2027 deadline is real, and the alternatives beyond it are expensive or narrow. For most organizations, the fastest way to de-risk the move to S/4HANA is to treat data as the critical path: decide what to migrate, cleanse at the source, resolve Business Partner and finance prerequisites early, run disciplined mock loads and reconcile business totals with clear sign-offs. Organizations that start the data stream now will reach go-live with cleaner data and fewer surprises, whatever approach they choose.
How Hanoi Technology Can Help
Hanoi Technology supports S/4HANA programs with data profiling, cleansing, migration engineering and reconciliation, delivered as projects or dedicated teams.