Middleware — The Key to Effective Integration and Project ROI
The layer between your storefront and your ERP is where integration budgets go to die, or where they pay for themselves...
Contents
Nobody calls the integration layer a project.
It’s a line item. “Connect the store to the ERP.” A developer, a couple of weeks, done.
Then it’s a Monday morning and the warehouse calls to ask why there’s nothing to pick. Orders stopped posting Friday night. Nobody knew, because nothing threw an error — the script kept running, the site kept taking orders, and the ERP kept waiting for data that never arrived.
The storefront was fine. The ERP was fine.
The thing between them was not.
In Module 01, line 05 of the migration cost stack was “backend systems integration — secure pipelines between checkout and your ERP, WMS, and POS.” This module is that line. I’ve served as architect and project leader on a custom ERP replacement and led four e-commerce implementations, so take this from someone who has actually run the business:
“Every system in your company can be healthy while your business is broken. That’s what the integration layer does when nobody owns it.”
Four lessons, a scorecard you can send to vendors, and the question I’d ask if I sat on your board.
Lesson One: Spaghetti is cheap to write and expensive to own
Past roughly $2 million in revenue, the stack multiplies. Online store. Retail point of sale. ERP. Accounting. Warehouse management. CRM. Each one arrived to solve a real problem, and each one speaks its own dialect.
The instinct is to wire them together directly — a script here, a webhook there. Point-to-point is genuinely cheap to write. That’s the trap. Six systems wired directly to each other is a bowl of spaghetti where every strand is load-bearing and none of them are documented.
And here’s the part nobody warns you about: that spaghetti has an expiration date you didn’t set.
Shopify releases a new API version every three months, named by date. Each stable version is supported for at least twelve months. When your script keeps asking for a version that has aged out, Shopify doesn’t slam the door — it falls forward and answers with the oldest version it still supports.
Read that again, because it’s the whole problem. Your integration doesn’t crash. It gets a perfectly good response, in a shape it wasn’t written for, and keeps going. The failure is silent, and you find it downstream — in a warehouse that has nothing to pick, or an inventory count that’s quietly wrong.
Rate limits work the same way. Shopify uses a leaky bucket: fill it and you get throttle errors until capacity drains back. Their own guidance is to back off, retry deliberately, cache what you reuse, queue and spread the work. All reasonable. All of it code somebody has to write — and point-to-point scripts almost never do, because they were a two-week line item.
Middleware is what that code becomes when you build it once instead of eleven times. One dispatcher that every system talks to: it cleanses payloads, maps fields, absorbs rate limits, retries what’s retryable, holds what isn’t, and leaves an audit trail you can replay when something goes wrong.
A rule I live by
Every connection needs a name on it.
If you can’t tell me who gets the alert when an order fails to post, you don’t have an integration. You have a script with good intentions.
Lesson Two: Six roads, one choice
There’s no universally correct answer here. The right one falls out of two things: how unusual your business is, and how complex your workflows are.
Run a custom product line, a heavily customized platform, and a custom-built ERP, and you will end up building. Run a stock catalog as a retailer or distributor, and one of the packaged options will serve you better and cost less.
Six middleware alternatives
Pick from your business model and your workflows — not from a vendor’s feature grid.
Lesson Three: Choose on five things, not fourteen
I’ve watched teams build forty-row comparison matrices. They always produce the same result: a tie, and a decision made on vibes two weeks later.
Five things decide this.
1. Compatibility. Your specific ERP, your specific version, your specific platform. Confirm the connector performs the function you need. “Supports NetSuite” is marketing, not a requirement met.
2. Business fit. Your real order flow, not a generic one. Product configurations, custom text, artwork files, production instructions. If you’re a manufacturer, this is where standard connectors usually run out of road.
3. Reliability. Can it detect a failed transaction, retry what’s temporary, prevent a duplicate order, and tell a human when it needs help? Lost orders and wrong inventory are what integration failures actually cost.
4. Total cost and ROI. License, transaction fees, implementation, maintenance, future enhancements. Model it at two or three times your current volume, because that’s the point of the project.
5. Future flexibility. The next system is always coming — accounting, CRM, shipping, WMS, manufacturing. A platform that carries several applications is worth more over five years than one that connects exactly two.
A rule I live by
Decide real-time versus batch per data type, not per project.
Orders and fulfillment want real time. Catalog updates and bulk pricing rarely do. Timely batch — small, frequent, scheduled — is the most underrated option in this whole business, because it fails politely.
Real-time is terrific. Ask what happens to your website, your middleware and your ERP when it fails. If the answer is a shrug, choose batch.
Lesson Four: Run it like a project, not a purchase
Middleware selection deserves the same rigor you gave choosing the e-commerce platform. It usually gets a fraction of it.
Assign a project leader. If the technical expertise isn’t in the building, get it or contract for it — but the project management accountability stays in-house, with someone respected enough to make decisions and hold a timeline.
Keep the team small. A handful of subject matter experts who know how the work actually happens. In my experience the best-performing teams on this are small and agile.
Then work the milestones:
Document today’s reality. Every business rule and process that moves data between the site and the ERP — including the manual ones. Especially the manual ones. They’re where the undocumented business logic lives.
Write the requirements. Most of them fall out of step one, along with the improvements you’ve wanted for years.
Issue an RFP to a short list. Short. Four serious vendors beat twelve polite ones.
Evaluate the responses against the scorecard, and decide which of the six roads you’re on and who your partner is.
Present the decision with cost-benefit, implementation strategy, timeline, ROI and the business risks named out loud.
A word to the next generation
Learn data mapping. Product identifiers, price structures, customer records, order formats — how a thing in one system becomes the same thing in another.
The platforms will change three times in your career. The mapping problem never does.
If I Sat on Your Board: The question I’d ask
Not which vendor. Not what it costs.
When this breaks at 2 a.m., who gets the alert — and what happens to the order that was in flight?
Three possible answers, and they tell you everything. Nobody knows means you’re running on hope. An email alias means the alert exists and nobody reads it. It queues, it retries, and here’s the person who owns it means you bought an integration instead of a script.
Your next step
Turn the considerations below into a weighted scorecard, send it with your RFP, and score every vendor against your requirements rather than their demo.
A vendor who answers all fourteen cleanly has done this before. One who dodges six of them has told you something important.
The integration RFP scorecard
Your storefront is what your customers see. Your middleware is what your business runs on.
Buy the dispatcher. Not the spaghetti.
Next in this series — Module 04: The Open-Source Paradox — Hidden Maintenance and DevOps Costs Exposing the true cost of self-hosting and calculating your three-year TCO.
About the author
Gary Q. Smith — President, GQS Direct, LLC
Gary pairs four decades of P&L-accountable direct marketing leadership with practitioner-level command of today’s commerce stack. He is currently an AI evangelist and practitioner and has led four e-commerce website implementations and integrations, built marketing databases, was architect and project leader for a custom ERP system, and managed omnichannel marketing strategy and communications for several businesses.
Most consultants have studied these problems. GQS Direct has owned them.
Start with a complimentary consultation →
The E-Commerce Implementation Series
Module 01 — Re-Platforming Is a Systems Project, Not a Web Design Project
Module 03 — Middleware: The Key to Effective Integration and Project ROI (you are here)
Module 04 — The Open-Source Paradox: Hidden Maintenance and DevOps Costs
Module 05 — Your B2B Buyer Is Not a Consumer With a Bigger Cart