Getting an MDM tool running is the easy part. You load your supplier data, set up permissions, configure validation rules. It takes a week, maybe two. Then someone asks: "So how does the ERP get this data?"
That question is where most MDM projects stall. Not because integration is technically hard, but because nobody planned for it. The MDM tool sits off to the side with perfect, governed data that nothing else consumes. A golden record nobody reads.
I have spent the past year watching mid-market IT teams connect Primentra to their ERP, CRM, data warehouse, and everything in between. Four patterns cover roughly 95% of what they need. None of them require middleware licenses or a dedicated integration team.
The one rule: master data flows outward
Before picking a pattern, get this straight. The MDM system is the authoritative source. Data flows from MDM to downstream systems, not the other way around. If you let the ERP push supplier changes back to MDM while MDM pushes changes to the ERP, you have built a conflict engine, not an integration.
The only exception is the initial load. When you first set up MDM, you pull existing data from wherever it lives today — probably your ERP. After that, the ERP becomes a consumer. New suppliers get created in MDM. Name corrections happen in MDM. The ERP gets the result.
This is not a philosophical stance. It is a practical one. Your ERP was not built to govern data. It was built to process transactions. Let each system do what it was designed for.
Pattern 1: scheduled file export
The oldest pattern in the book, and still the most common. The MDM system exports a CSV or Excel file on a schedule — nightly, hourly, whatever matches your business rhythm. A downstream system picks it up and imports it.
Boring? Absolutely. Reliable? Extremely. Every ERP on the planet can import a CSV. Every ETL tool can read one from a shared folder. You do not need to figure out OAuth tokens, API versioning, or retry logic. You need a file share and a Windows Task Scheduler job.
I would estimate that 60% of our customers start here. Not because they lack technical sophistication, but because their supplier list changes ten times a week, not ten times a minute. A nightly export handles that fine.
Pattern 2: staging table sync
If you are a SQL Server shop (and most Primentra users are), this is the pattern that feels native. Instead of exporting a file, the MDM system writes governed data directly into a staging table on the target database. A stored procedure or SSIS package picks it up from there.
The flow looks like this:
This pattern is popular because your DBAs already know how to build it. No new tools, no new languages. It is T-SQL all the way down. The staging table strategies we wrote about for imports work in reverse for exports.
The downside: it requires network access between databases. If your MDM runs on Server A and your ERP runs on Server B, you need a linked server or an intermediate file drop. For organizations with strict network segmentation, this adds a conversation with the security team.
Pattern 3: REST API
When a downstream system needs current data on demand, an API is the right answer. The consuming system calls the MDM API, gets the current version of a record, and uses it. No files sitting on a share, no schedule to maintain.
Primentra ships a REST API that exposes entity data via standard HTTP endpoints. A warehouse tool or custom application can call GET /api/v1/entities/{id}/records and get back JSON. Authentication is a single API key in the header. No OAuth dance, no token refresh logic.
Two modes matter here:
Pull
The consumer calls the MDM API when it needs data. Good for dashboards, on-demand lookups, and systems that validate master data at transaction time.
Push
The MDM system calls the consumer's API when data changes. Good for keeping a CRM or e-commerce catalog in near-real-time sync. Requires the consumer to have an API endpoint that accepts updates.
Most mid-market teams use pull. It is simpler and the consuming system controls the timing. Push adds complexity: you need to handle retries, dead-letter queues, and the question of what happens when the target system is down at 3 AM.
Pattern 4: hybrid (batch + API)
In practice, most organizations end up here. Different systems have different needs. Your data warehouse wants a nightly batch load because it rebuilds dimensions overnight anyway. Your CRM wants near-real-time because the sales team needs current customer data during calls. Your ERP gets a staging table sync every hour because that is what the DBA built five years ago and it works.
This is fine. The MDM system does not care how many consumers it has or which pattern each uses. The data is governed once, in one place. Each downstream system picks the delivery method that fits its technical constraints and freshness requirements.
What about middleware?
Enterprise MDM vendors love to sell a middleware layer. MuleSoft, Dell Boomi, Informatica Cloud — pick your poison. These tools sit between the MDM system and everything else, routing data, transforming schemas, handling retries.
For a company with 200 integrations across 40 systems, middleware earns its keep. For a mid-market team connecting an MDM tool to an ERP, a data warehouse, and maybe a CRM? Middleware adds cost and complexity that does not match the problem. You are paying six figures a year for a tool whose primary job is moving a CSV from point A to point B.
A SQL Agent job handles it. So does a 20-line PowerShell script, or the Primentra staging scheduler.
The threshold where middleware starts making sense: when you have more than five consuming systems with different data formats, or when you need guaranteed delivery with complex retry logic across unreliable networks. Below that threshold, scripting and native database tools handle it with less overhead and fewer vendor contracts.
The part everyone forgets: monitoring
An integration that works today will break tomorrow. The file share fills up. The API key expires. The staging table schema drifts after someone adds a column to the ERP. You need to know when it breaks before the business does.
For batch integrations, the minimum viable monitoring is: did the job run? Did it process the expected number of records? Did it finish without errors? A SQL Agent job with email alerts on failure covers this. Check the audit trail periodically to make sure changes are flowing through.
For API integrations, log every call. Not the full payload — just the timestamp, endpoint, status code, and record count. When the CRM stops pulling data for 48 hours, you want to know about it from your logs, not from a sales manager asking why customer addresses are stale.
Start small, expand as needed
The biggest integration mistake I see: teams try to connect everything on day one. They want the ERP, the CRM, the warehouse, the BI tool, the e-commerce platform, and two legacy Access databases all wired up before go-live.
That turns a two-week MDM rollout into a six-month integration project. Instead: get the MDM system running with one domain (suppliers, say). Connect the one system that hurts most (probably the ERP). Prove the pattern works. Then add the next consumer.
Each new connection goes faster than the last. The first ERP sync might take a week to build and test. The data warehouse export after that takes a day, because you already have the export queries and the file format figured out. By the third system, it is routine.
Frequently asked questions
How do you integrate an MDM system with an ERP?
The most common pattern is batch synchronization: the MDM system exports governed master data on a schedule (nightly or hourly) and the ERP imports it via flat file, staging table, or API. For real-time needs, use API-based push where the MDM system calls the ERP API whenever a record changes. The key principle is that master data flows one direction — from MDM to ERP — with the MDM system as the authoritative source. Changes in the ERP should be limited to transactional data, not master data fields.
What is the difference between batch and real-time MDM integration?
Batch integration syncs data on a schedule — typically overnight or every few hours — using file exports, staging tables, or bulk API calls. Real-time integration pushes changes immediately as they happen, usually via REST APIs or event streams. Most mid-market organizations use batch for data warehouses and reporting systems, and real-time only for systems that genuinely cannot wait, such as e-commerce pricing or fraud detection. Batch is simpler to implement, easier to monitor, and handles errors more gracefully.
Should master data flow from MDM to other systems or both directions?
Master data should flow one direction: from the MDM system outward. The MDM tool is the authoritative source; downstream systems consume it. If you allow changes in both directions (bidirectional sync), you re-create the consistency problem MDM was supposed to solve — two systems disagreeing about which version of a supplier record is correct. The exception is initial data loading: you may pull existing data from an ERP or CRM into the MDM system once during setup, then govern it centrally going forward.
How do you keep a data warehouse in sync with MDM?
The standard approach is a nightly batch export from the MDM system into the warehouse staging area. The MDM tool exports governed dimension data — suppliers, customers, products, cost centers — as flat files or directly into staging tables. The warehouse ETL process picks these up during its regular load cycle. This ensures dimension tables always reflect the governed version of master data, not whatever version each source system happens to have. Most MDM tools support scheduled exports or REST API endpoints that ETL tools can call.
MDM that connects to what you already run
Primentra runs on SQL Server, exports to staging tables natively, and ships with a REST API for real-time consumers. No middleware required. No integration consultants. The 60-day trial includes everything — connect it to your ERP and see if the pattern holds.