IntelliFabric

How do you get visibility across sites when every warehouse runs a different WMS?

4 min read Reviewed October 6, 2026Answered by the IntelliFabric delivery team
Short answer

Conform the metrics rather than consolidating the systems. Each warehouse keeps its own WMS; a separate read-only pipeline lands each site's data in OneLake, and one semantic model maps every site's fields to a single shared definition of a pick, a line and a shipment. Cross-site comparison then works without a WMS consolidation programme, and the first site is live in weeks rather than quarters.

Key takeaways
  • 01Conformance belongs in the semantic layer, not in the source systems. Every WMS keeps running and is accessed read-only; the mapping from its fields to the shared metric definition lives in one versioned place you can audit, instead of being re-implemented inside a dozen report-level formulas that drift apart.
  • 02The real deliverable is a metric dictionary, one row per KPI. For each metric it fixes the grain (line, unit, carton or order), which WMS event counts as the timestamp (pick confirm, task close or wave complete), the inclusion rules for cancelled lines, kitting, cross-dock and returns, the unit-of-measure conversion between eaches, cases and pallets, and the site calendar, shift boundary and time zone. Sites disagree on those five things far more often than the SQL is wrong.
  • 03Extraction surface varies by site and sets the sequencing. A cloud WMS generally exposes a REST API and a scheduled flat-file extract; an on-premises or vendor-hosted WMS is normally read from a SQL replica or a reporting schema rather than from production, because report queries against a live pick-path database are felt on the floor. Firewalled sources are reached through an on-premises data gateway, which opens an outbound connection only.
  • 04Incremental refresh keys off a row-level watermark, usually a last-modified timestamp, so only changed records move. Two WMS-specific failure modes break it: tables updated in place without a trustworthy modified column, where the transaction or history table has to be read instead, and sites in different time zones writing local time, where a naive watermark silently skips late-arriving rows. Both surface during the first site, not at go-live.
  • 05When one site changes WMS, only that site’s pipeline and field mapping are rebuilt — the conformed model, the KPI definitions and every dashboard stay as they are. Record the mapping with an effective date and keep the already-conformed history in OneLake, or the cutover appears as an unexplained step change in the trend.
  • 06The honest limit: if a site does not capture the event at all, no semantic layer can manufacture it. A paper-pick or scan-at-pack operation has no line-level pick timestamp, so it can be compared at order level and no further until the process on the floor changes. That is a warehouse decision, not a reporting one.

Where to go deeper

For the full explainer on this topic rather than this specific question, see the detailed guide on the blog.

Related questions, answered

Do we have to replace our WMS platforms to get one set of cross-site numbers?

No. Each site keeps its WMS, and access to it is read-only — a pipeline reads from a replica or reporting schema and writes nothing back. The comparison is built one layer up, where each site’s fields are mapped to a shared metric definition. A WMS migration is an operations programme carrying go-live risk on the floor; cross-site reporting does not require one.

What do we need from each site before a cross-site metric can be trusted?

Three things per site: a read-only account against a replica or reporting schema, a named person who can state which WMS event the site treats as a completed pick, and a cross-reference for SKU and facility codes. The third is usually the bottleneck. Where two sites code the same item differently and nobody owns the mapping, per-SKU comparison stays wrong however well the model is built.

How do you extract data from a WMS that has no API?

Through the database, or through a file drop. Most on-premises and hosted WMS deployments are read from a SQL replica or a reporting schema rather than from production, because reporting queries against a live pick-path database affect the floor. Where the server sits behind a firewall, an on-premises data gateway makes an outbound connection, so no inbound ports are opened. Some sites are easiest to read from a nightly extract to SFTP.

What happens to our reported history when one site switches WMS?

Only that site’s pipeline and field mapping are replaced; the conformed model, KPI definitions and dashboards are untouched. The risk sits in the trend line. Record the mapping with an effective date and keep the already-conformed history in OneLake, otherwise the cutover shows up as a step change in pick accuracy that nobody can explain six months later.

When is a cross-site reporting layer the wrong answer?

Three cases. When a site does not capture the event at all — a paper-pick operation has no line-level timestamp, and no semantic layer can invent one, so that site can only be compared at order level until the process changes. When two sites share one WMS, which needs a model, not a programme. And when the real requirement is one live inventory position for order promising; that is a WMS or ERP job.

What is the sensible rollout order across five or six sites?

One site first, end to end, which forces the metric dictionary to be written down. Then a second site on a different WMS, because a mapping only proves itself when two sources have to agree. The comparison layer and the shared site dimension come third. First-module delivery runs four to six weeks; each additional site is mostly mapping work rather than new architecture.

Sources

Figures on this page: 4–6 weeks · an on-premises data gateway · data stays in your tenant

See the mechanism, not the marketing

The architecture, the pipelines, and the governed semantic model that make this work on your own tenant.

See how it works
Or read the full guide to integrations & data

People also ask

  • How do you compare pick accuracy between two warehouses that record it differently?
  • Can Microsoft Fabric read from several warehouse management systems at once?
  • Which partner can connect multiple WMS platforms into one reporting model?
  • How long does it take to add a second warehouse to an existing dashboard?
  • What is a conformed dimension in a multi-site warehouse data model?
More answers
Choosing a partner

Can we see a demo running on our own ERP data before we commit?

4 min read
Build vs buy

Is there a Microsoft Fabric solution that comes with KPIs already built so we don't start from a blank canvas?

4 min read
Choosing a partner

Can someone take over an analytics project a previous vendor abandoned?

4 min read