People have seen the headline.
“13 ERPs unified in 90 days.”
They’ve read the HFW story. They’ve seen the dashboards. They’ve heard the outcomes.
And the next question is always the same:
How do you actually do this in real life?
Not in theory. Not in a slide deck. At scale. Without blowing up timelines or budgets.
That is what this article is about.
This is not a case study. This is the guidance behind the case study.
Where this pattern really started
I want to start long before Microsoft Fabric existed.
In 2016, I was at KMG Chemicals. Like many organizations that grow through acquisition, we did not have “an ERP.” We had many.
SAP in multiple flavors.
SAP ECC.
SAP S/4.
Macola.
Infor.
And a few more systems layered in for good measure.
Eleven ERPs in total.
Every acquisition brought value, but it also brought fragmentation. Each system had its own chart of accounts, customer identifiers, product codes, and reporting logic. Leadership wanted consolidated visibility, but the reality was Excel files, manual reconciliation, and long reporting cycles.
It took us about a year and a half to unify that environment. Not because the technology was hard, but because we were learning the pattern while doing the work.
That was the moment I realized something important:
The hard part of multi-ERP analytics is not the tools.
It is the architecture decisions you make before you write your first query.
That pattern followed me into every role after that. Different companies. Different industries. Different systems. Same fundamental problem. Same solution.
Years later, at Data Crafters, we applied that same pattern again. This time at HFW. And this time, Siva Mani was the principal consultant leading the execution.
Microsoft Fabric didn’t invent the pattern.
It made it affordable, faster, and repeatable.
Why multi-ERP analytics usually fails
Most organizations approach this problem backwards.
They believe they must:
- Standardize ERPs first
- Harmonize charts of accounts first
- Clean all master data first
- Finish migration first
- Then build analytics
- That approach feels logical. It is also why these initiatives take years.
What actually happens:
- ERP migrations stall
- Leadership waits for visibility
- Value is deferred until the end
- Teams lose momentum
At HFW, leadership made a deliberate decision not to wait.
Integration happened during migration, not after.
The real goal: normalize business meaning=data, not systems
Here is the mental shift that matters.
We did not try to make every ERP look the same.
We focused on normalizing business concepts:
- What is a customer?
- What is a project?
- What does revenue mean?
- What does backlog mean?
- What does “active” actually mean?
Once those concepts are consistent, the source system becomes secondary.
This is where architecture matters more than tooling.
The Medallion architecture, used with intent
You will hear a lot of people talk about Medallion architecture. Bronze. Silver. Gold.
What matters is how you use it.
Bronze: respect the source
- In the bronze layer:
- Each source system lands in its own schema
- No forced alignment
- No early transformations
- No clever logic
This is deliberate. Bronze is about traceability and trust.
Silver is the real secret
If there is one thing to remember from this article, it is this:
Silver is where complexity belongs. Not gold.
In the silver layer:
- Each source system gets its own silver schema
- Transformations are source-specific
- Business logic is handled independently per ERP
Why this matters:
Every ERP has quirks. Every acquisition has exceptions. Trying to handle all of that in a single unified query is how models become unmaintainable.
Instead:
- Contain complexity where it originates
- Keep transformations readable
- Make every source independently testable
This is how you avoid one massive SQL statement that nobody wants to touch six months later.
All so that you can arrive on a common definition of Customer, Product, Invoice Table etc.
It should:
- Align columns
- Standardize data types
- Perform heavy transformations
- Contain conditional logic per source
- Fix data quality issues
The unified view should be boring
This is counterintuitive for many teams.
The append view that unifies all ERPs should be simple. Almost boring.
It should:
- Append rows
It should not:
- Perform heavy transformations
- Contain conditional logic per source
- Fix data quality issues
If your unified view is complex, the architecture is wrong.
The work should already be done before the append.
End-to-End Architecture:
Master data and keys: the part most teams underestimate
This is where many multi-ERP projects quietly fail.
In a single-ERP system, customer C1000 can only be customer C1000.
In a multi-ERP world, customer C1000 might exist in five different companies and be five completely different customers.
If you do not handle this intentionally, your model will break. Not immediately. But eventually.
The solution is not complicated, but it must be disciplined.
Standardized prefixes by ERP and source
Every shared dimension must use standardized prefixes:
- Customer
- Product
- Project
- Vendor
- Any master entity that crosses systems
For example conceptually:
EntityA_CUST_1000
EntityB_CUST_1000
Now they are unambiguous. Always.
Metadata is not optional
Every fact table should carry metadata:
- Source system
- ERP identifier
- Load timestamp
This serves three purposes:
- Traceability
- Debugging
- Scalability
When a new ERP is onboarded, it follows the same rules. No special handling. No Power BI model changes. No rework.
That is what makes this approach sustainable.
Why this scales without breaking Power BI
When prefixes and metadata are standardized:
- The Power BI semantic model does not need to change
- Measures remain stable
- New ERPs flow automatically
- This is critical.
If every new acquisition requires reworking the semantic model, you have not built a platform. You have built a project.
At HFW, this discipline is what allowed rapid onboarding without regression.
Where Microsoft Fabric changes the equation
This pattern existed before Fabric.
Fabric makes it practical.
One platform:
Ingestion
Transformation
Storage
Semantic modeling
No stitched-together tooling. No complex orchestration. No heavy operational overhead.
This is why this approach is now accessible to organizations that previously could not justify the cost or complexity.
Fabric does not remove the need for good architecture.
It rewards it.
From experience to execution at HFW
At HFW, this pattern was executed with intent.
Siva Mani served as the principal consultant leading the implementation. The team did not chase perfection. They chased clarity.
Integration ran in parallel with ERP migration and new integration from new acquisition.
Complexity was isolated.
Master Data was not an afterthought.
The unified view stayed simple.
The result was not just speed. It was confidence.
Leadership could finally see the portfolio. Each business unit could trust its numbers. And the foundation was set for what comes next.
The real secret
The secret to unifying multiple ERPs is not a feature.
It is not a dashboard.
It is not even Microsoft Fabric.
The secret is architectural discipline:
Contain complexity
Standardize meaning
Treat Master Data/keys with respect
Design for the next acquisition, not just the current one
When you do that, Fabric becomes the accelerator it was meant to be.
So when somebody tells you we have to get your data in one place or clean it up first before we can see them together, now you know better.
