ECC to S/4HANA greenfield data migration — designed, built and reconciled.
When a clean core is worth the extra load work
A greenfield move to S/4HANA rebuilds configuration from scratch and carries over only the data the new design needs: master data, balances and open items. You gain a clean core; you take on a serious migration workstream in return. Here is how we run it.
The old configuration no longer fits
Chart of accounts, org structure or costing design grew around decisions nobody would repeat today. Converting them in place carries the problem forward.
Heavy modifications to retire
Years of custom code and enhancements that duplicate what standard S/4HANA now does. Greenfield is the moment to drop them rather than remediate them.
Several systems becoming one
Multiple ECC instances from past acquisitions, each with its own conventions. A new target lets you agree one set of rules instead of merging three.
Process redesign is the real goal
The business case is new ways of working, not a technical upgrade. A new implementation keeps the design conversation open instead of anchoring it to the old system.
What actually moves
A greenfield load is deliberately narrow. The object list is agreed early and frozen, because every extra object adds a mapping, a test and a reconciliation.
Finance
- G/L accounts and chart of accounts
- Cost centres, profit centres, internal orders
- G/L balances at cutover
- Open AR and AP items
- Fixed assets with accumulated depreciation
- House banks and bank master
- Tax codes and tax determination
Logistics
- Material master and views
- BOMs, routings, work centres
- Purchasing info records and source lists
- Open purchase orders
- Open sales orders and contracts
- Inventory by plant and storage location
- Batches and serial numbers
Master data
- Business partners (customer/vendor integration)
- Pricing and condition records
- Output determination
- Credit management master data
- Employees and org assignment where in scope
Cross-cutting
- Organisational structure and mapping
- Currencies and exchange rates
- Number ranges
- Document types and reason codes
- Legacy key to new key cross-reference
History stays behind. Greenfield moves balances and open items, not years of posted documents — legacy reporting is served from the retired system or an archive, and that decision belongs in the business case from day one.
Business Partner conversion is usually the biggest single workstream
S/4HANA replaces separate customer and vendor masters with one Business Partner. On paper it is a data model change; in practice it surfaces every duplicate, every inconsistent naming convention and every one-off record that two departments created independently. Teams routinely underestimate it.
- Duplicate detection and merge rules agreed with the data owners, not invented by the migration team
- Grouping, roles and number ranges designed before the first load, because they are painful to change afterwards
- Customer and vendor records representing the same legal entity consolidated into one partner carrying both roles
- Bank details, tax numbers and addresses validated on the way in, not after the first payment run fails
- A legacy-to-new key cross-reference kept for the whole programme, so open items and documents still tie back
Six phases, four rehearsals
The durations below are typical ranges for a mid-sized single-instance migration. Multi-instance and multi-country programmes stretch the middle phases; they do not change the shape.
- 0101
Discover and profile
2–4 weeksProfile the source system before promising anything: record volumes, field fill rates, duplicate density, orphaned records. The output is an object list with a named business owner per object and a data quality baseline everyone has seen.
Object catalogueData quality baselineOwner per object - 0202
Design and map
4–8 weeksField-level mapping from source to S/4HANA target structures, plus value mapping for every code that changes. Rules are written where the business can review them, not buried in transformation code.
Field mappingValue mapping tablesTransformation rules - 0303
Build extractors and loads
runs in parallelMigration Cockpit objects for everything standard, staging tables for volume, and custom extractors only where the standard object genuinely does not fit. Every load is repeatable and restartable from the start.
Migration Cockpit objectsStaging tablesCustom extractors - 0404
Mock loads
3–4 cyclesLoad, measure, reconcile, cleanse at the source, repeat. Each cycle produces runtimes that feed the cutover plan and a defect list that goes back to the data owners. The last cycle should be boring.
Runtime measurementsDefect logReconciliation pack - 0505
Cutover
the weekendFreeze, final extract, load in the agreed sequence, reconcile against the sign-off pack, then a documented go/no-go with named decision makers. Nothing in the sequence is attempted for the first time here.
Cutover runbookSign-off packGo/no-go decision - 0606
Hypercare
4–6 weeksThe first month-end close is the real test. We stay through it, with the mapping team available for the corrections that only surface once real transactions hit the migrated balances.
First close supportCorrection logHandover
How we prove the load is correct
Every object has a reconciliation defined before it is built. Sign-off is a document, not a conversation.
Counts and control totals
Record counts per object and per company code, reconciled between extract, staging and target. Differences are explained line by line or the load does not pass.
Trial balance to the cent
G/L balances per company code, account and profit centre matched against the legacy trial balance in both local and group currency.
Open item ageing
AR and AP open items compared by ageing bucket and by partner, so a total that matches for the wrong reasons still gets caught.
Asset history sheet
Acquisition cost, accumulated depreciation and net book value reconciled against the legacy asset history sheet per asset class.
Stock quantity and value
Inventory matched per plant, storage location and material, with valuation reconciled against the legacy stock account.
Traceability both ways
Every migrated record carries its legacy key, so auditors can walk from a new document back to its source and back again.
What we build with
Standard where standard works, custom only where it earns its place.
SAP Migration Cockpit
Staging tables for volume loads, file uploads for the long tail. The standard migration objects cover most of the catalogue and stay supportable after we leave.
Migration Object Modeler
LTMOM extensions where the standard object is close but not complete — added fields, changed rules, custom target structures.
Custom extractors
ABAP or CDS-based extraction from the legacy system where source data needs joining, filtering or de-duplicating before it is fit to stage.
Our own migration tooling
For mappings that outgrow spreadsheets: versioned field and value mapping, custom business logic, and repeatable runs with a full audit trail.
What we design out early
These are the failure modes that turn a migration into a delayed go-live. All of them are avoidable, and all of them are cheaper to fix in month one.
Frequently asked
Can we bring historical documents across in a greenfield migration?
Technically some can be reconstructed, but it is rarely a good idea. Posted documents from a different configuration will not behave like native S/4HANA documents, and reconciling them consumes effort that adds no operational value. The usual answer is balances and open items in S/4HANA, history in an archive or a read-only legacy system. If retaining live history is genuinely a requirement, a selective transition is the better path.
How long does a greenfield data migration take?
For a single-instance, mid-sized landscape the data workstream typically runs six to nine months alongside the wider programme, with three to four mock load cycles inside that. Multi-country or multi-instance programmes extend the design and mock phases rather than changing the structure.
How many mock loads do we actually need?
Three at minimum, four is comfortable. The first proves the pipeline runs, the second exposes real data quality, the third rehearses the sequence with realistic runtimes, and the fourth exists so that the third one is allowed to go badly.
Who owns data cleansing — you or us?
You own the decisions, we own the mechanics. We find and quantify the defects, propose rules and provide the working lists; the business decides what counts as a duplicate and which record survives. Migration teams that make those calls alone tend to be overruled at go-live.
What happens to our custom fields?
They are assessed individually. Some map to standard S/4HANA fields that did not exist in ECC, some move to extension fields on the target, and some turn out to be unused and get dropped. Greenfield is the cheapest moment you will ever have to remove them.
Can you work alongside our existing system integrator?
Yes, and it is a common setup. We take the data migration workstream as a self-contained package with its own reconciliation gates, and plug into the programme cutover plan.
Planning a move to S/4HANA?
Bring us your source landscape and your target go-live date. We will walk you through the object list, the realistic effort, and where the schedule is most likely to slip.