Posted in Digital Commerce
June 8, 2026
architecture in practice
How an Acumatica manufacturer avoided a rebuild by getting the architecture right first
A mid-market manufacturer running on Acumatica came into the architecture conversation with the platform shortlist already narrowed to one. The discovery work showed the chosen platform could not model the contract pricing the business depended on without significant custom integration. A different architecture decision, supported by the discovery rationale, produced a different platform recommendation and prevented what would almost certainly have been a multi-quarter rebuild eighteen months in.
Key takeaway
Slowing down for two weeks of architecture work saved this manufacturer a multi-quarter rebuild.
The situation: pressure to pick a platform fast
The leadership team had committed publicly to launching a new commerce experience by the next fiscal year. The platform shortlist had been built from a peer-company recommendation and a strong demo. Discovery looked like a tax on the timeline; the implementation team was ready to start. The CFO asked for a two-week sanity check before signing the contract. That conversation surfaced a contract-pricing structure that the chosen platform could not model without custom integration, plus an account-hierarchy pattern that would have required significant rework to expose cleanly.
What discovery surfaced
The business ran on contract pricing for the top fifteen percent of accounts, which generated nearly seventy percent of revenue. Each contract had its own escalator clauses, volume tiers, and product carve-outs encoded in Acumatica through a customization that had been refined over years. The originally chosen platform could read net prices from Acumatica but could not honour the escalator and carve-out logic without an integration layer that effectively duplicated the customization.
The account hierarchy was the second surprise. Ship-to and bill-to relationships drove approval routing and credit decisions, and the structure included several edge cases that the originally chosen platform would have rendered awkwardly. A different architecture path made these patterns express naturally; the originally chosen path made them fight the platform.
The architecture decision and why
The discovery sprint produced a written architecture rationale that pointed to a middleware-led integration pattern with Acumatica as the system of record and a different commerce platform handling the buyer experience. The chosen integration partner had deep experience with the Acumatica contract-pricing customization; the chosen platform supported the account-hierarchy patterns natively. The rationale named the originally favoured platform as the runner-up and documented why it was set aside (contract-pricing model incompatibility, account-hierarchy mismatch, integration cost projected to scale with custom-rule maintenance).
Presenting the recommendation to the executive team required candour about the gap between the original assumption and the discovery finding. The CFO accepted the recommendation because the discovery had quantified the cost of proceeding with the original platform against the cost of switching now. The eventual recommendation matched the operational truth; the original plan would have produced a rebuild.
What the manufacturer avoided
Three things. First, the mid-implementation rework that almost certainly would have happened when the contract-pricing customization in Acumatica met the originally chosen platform's incompatible pricing model. Second, the launch-date slip that would have produced when the rework absorbed the contingency buffer. Third, the rebuild that follows when a launched site contradicts the contracts the customer signed; rescue engagements for that pattern typically run twelve to eighteen months.
Quantifying the avoidance is difficult precisely because it did not happen. The directional math at the time put the avoided cost at several multiples of the discovery investment and a launch-date saving of at least two quarters. The manufacturer still tells the story internally as the moment they learned that discovery is part of the project, not adjacent to it.
What changed in the next 18 months
The site launched on schedule against the architecture rationale. Customer-specific pricing flowed cleanly from Acumatica through the integration layer. Approval routing followed the account hierarchy without rework. Sales reps adopted the storefront for assisted-sell workflows because the data matched what they saw in Acumatica. None of those outcomes is exotic; each one traces back to the architecture decision that respected the operating model rather than fighting it.
The lesson is not that the original platform was bad. It was a poor fit for this particular operating model. A different business with a different model would have been well served. The decision is about fit, not about brand. The discovery work surfaced the fit question while it was still cheap to answer; the platform decision flowed from the answer. Read the discovery and strategy framework for the methodology behind the engagement.
Related Articles
Commerce architecture fit for complex B2B: the decision layer before platform selection
- The architecture fit report: where B2B ecommerce projects fail before the first line of code
- ERP as source of truth vs commerce as source of truth
- The ERP-commerce readiness framework
- Why your ERP breaks when you bolt ecommerce on top
- Acumatica + DiamondBack Truck Covers
- Eagle Fence Distributing — Acumatica manufacturer spotlight
Frequently Asked Questions
How does the right commerce architecture decision prevent a rebuild?
By making the architecture choice fit the operating model rather than fighting it. A platform that cannot model the business logic produces a storefront that contradicts the contracts and a buyer experience the sales reps will not trust. Discovery surfaces the fit question while it is still cheap to answer; the platform decision then flows from the answer rather than being made on instinct.
What is the role of Acumatica in this kind of architecture decision?
Acumatica often holds the system-of-record customization (pricing, contracts, account hierarchy) that the commerce decision has to honour. The architecture decision is mostly about how cleanly the commerce layer reads from and writes to Acumatica without contradicting it. The integration partner experience matters because Acumatica customization patterns vary widely across deployments.
How long does an architecture diagnostic for a project like this take?
For mid-market manufacturers, a focused diagnostic usually runs two to four weeks. A full sprint runs six to eight weeks. The diagnostic in this case ran two weeks and produced a defensible recommendation against the immediate platform decision; a full sprint would have added more rigour to the operating-model statement but the diagnostic was enough to flip the call.
How do you present a discovery finding that contradicts the executive team's assumption?
With candour and quantified math. Name the gap between the original assumption and the discovery finding. Quantify the cost of proceeding with the original assumption against the cost of switching now. Most executive teams accept the recommendation when the math is honest and the alternative is documented. Sympathetic framing helps; pretending the original assumption was always wrong does not.
What if the architecture decision had pointed back to the original platform?
The team would have proceeded with confidence rather than instinct. Discovery is the work that produces the rationale, regardless of which direction the rationale points. The value is in the defensible answer, not in changing the original assumption for its own sake. Sometimes the original assumption survives; sometimes it does not; the discovery is what makes the survival meaningful.
How does this case connect to the Acumatica commerce ecosystem pillar?
The Acumatica pillar covers the full ecosystem of platforms, middleware partners, and integration patterns Acro composes around Acumatica deployments. This case sits at the architecture decision that precedes any platform choice. Together the two pieces give an executive team both the upstream decision framework and the downstream ecosystem picture.
Next step
Get the foundation right before you build.
For readers scoping a platform decision or wanting a full architecture recommendation.