Global Agri-Science: consolidating four SAP ECC instances onto one HANA platform
A global agri-science enterprise ran four SAP ECC instances, each holding its own version of master data. Unolabs consolidated them onto a single SAP HANA platform through a BODS-driven migration factory, with SAP MDG governing the harmonised entities. The reusable foundation has since cut onboarding effort for new domains by 40%.
A concise view of impact and engineering focus.
4 to 1 instance consolidation
40% reduced onboarding effort
Global data harmonisation across all four estates
Four systems of record, four versions of the truth
A global agri-science enterprise operated four disparate SAP ECC instances, each serving different parts of the business and each maintaining its own version of master data. Each had been a reasonable decision at the time it was taken, which is how estates like this one usually arrive.
The consequences compounded over time. The same entities existed in multiple conflicting forms across instances, reporting had to be stitched together manually across landscapes, and every instance carried its own maintenance overhead, upgrade cycle and support burden.
Cost was the smaller problem. With four systems of record there was no authoritative answer to basic global questions, and no realistic path to S/4HANA while the estate remained fragmented — a modernisation blocked not by licensing or by capability but by an unsettled argument about which record was correct. Those arguments do not resolve themselves, and they get more expensive with every year of divergence.
Instance consolidation looks like an infrastructure project but is really a master-data project — the hard work is deciding which of four conflicting records is the truth, at scale, for every entity.
How a migration factory made four consolidations tractable
We led the consolidation of all four ECC instances into a single SAP HANA platform, built around a BODS-driven migration factory: a repeatable pipeline that extracted, transformed, harmonised and loaded data landscape by landscape rather than treating each migration as a bespoke effort. Mapping rules, validation checks and reconciliation logic were engineered once and reused.
In parallel we implemented SAP MDG to give the unified platform centralised master data ownership and governance workflows, so harmonised entities gained named stewardship and controlled change processes. That is the mechanism preventing a consolidated estate from fragmenting again, and it is the part most often deferred when a programme runs tight.
SAP BI/BW modernisation consolidated global reporting onto the new platform, and OutSystems delivered the specialised supporting business applications alongside the core. The architecture was deliberately kept S/4HANA-ready throughout, so the eventual move would not require re-litigating decisions already taken during the consolidation. Protecting that optionality cost design time and was worth it.
- BODS-driven migration factory from 4 ECC instances to unified HANA
- SAP MDG for global master data governance and stewardship
- SAP BI/BW modernisation for consolidated global reporting
- OutSystems integration for specialised business application delivery
- S/4HANA-ready architecture to future-proof the investment
A migration factory converts four migrations into one engineered pipeline run four times — the economics and the error rates of that approach are fundamentally different from four bespoke projects.
The outcome: one source of truth, and the tooling to reuse it
The consolidation delivered a single trusted source of truth across what had been four separate global landscapes, with correspondingly reduced infrastructure complexity and lower maintenance costs. That much was the stated objective.
The more durable value is the reusable foundation. The harmonised data model, governance workflows and migration tooling built for the consolidation have since cut onboarding effort for new domains by 40%, because each new domain lands on established patterns instead of starting from scratch. Consolidation programmes are usually justified on infrastructure savings alone, and that undersells them: the tooling built to do the job is the part that keeps paying.
The estate is also S/4HANA-ready, so the eventual move becomes a platform upgrade rather than another multi-year harmonisation programme. That is the compounding return on the factory approach: the argument about which record is correct was settled once, under controlled conditions, instead of being reopened at every subsequent milestone.
What we'd flag: consolidation only stays consolidated if governance keeps operating — SAP MDG workflows require sustained business-side stewardship after go-live, and that ongoing commitment is part of the total cost of ownership, not an optional extra.
What to carry into the next sprint
Takeaway
Settle which conflicting record is correct before scheduling any migration wave.
Takeaway
Engineer the migration once as a factory, then run it per landscape.
Takeaway
Fund master data stewardship after go-live, or the consolidation quietly reverses.
Frequently asked questions
- What breaks first in an SAP instance consolidation?
- Master data. Four ECC instances holding four versions of the same entity means the hard work is adjudication rather than extraction: deciding which record is correct, at scale, for every entity in scope. Teams that plan a consolidation as an infrastructure exercise tend to discover this only after the migration schedule has already been committed.
- Why build a migration factory instead of migrating each instance?
- Because mapping rules, validation checks and reconciliation logic are the expensive parts, and they are largely the same each time. A BODS-driven factory converts four migrations into one engineered pipeline run four times. The economics and the error rates of that approach differ fundamentally from four bespoke projects carrying four sets of assumptions.
- What stops a consolidated estate from fragmenting again?
- Sustained stewardship, not architecture. SAP MDG supplies centralised ownership and governance workflows, but those workflows need business-side stewards after go-live to keep operating. That ongoing commitment belongs in the total cost of ownership rather than being treated as an optional extra, and it is the line most quietly defunded once the programme closes.
- Does consolidation have to happen before an S/4HANA move?
- It is not a formal prerequisite, but a fragmented estate makes the move considerably harder. With four systems of record there is no authoritative answer to basic global questions, so every migration decision reopens a reconciliation argument. Consolidating first onto a unified, S/4HANA-ready HANA platform turns the eventual move into a platform upgrade instead.
- What is the 40% onboarding reduction measured against?
- Against the effort of onboarding a new domain before the consolidated foundation existed. The harmonised data model, governance workflows and migration tooling built during the programme are reused, so each new domain lands on established patterns rather than starting from scratch. The figure reflects reuse on this estate; ask us what it counted, and over how many domains.
Settle which of your conflicting records is the correct one
We will assess your instances against a consolidation target and show you where master data genuinely conflicts, what a migration factory would reuse, and what stewardship the result will need.
Book a Consolidation Review