Which layer is actually broken? Five questions that separate them
A connector complaint almost always arrives as one sentence: "the integration keeps breaking". Underneath that sentence are three completely different problems with three completely different price tags. Run these five questions in order and stop at the first one that gives you a clear answer.
The point of running them in this order is that the cheap diagnoses come first. Most teams start at question five and buy a replatform for a problem that question one would have caught.
Does the failure name a record, or a rule? "Item ABC failed to sync" is a data problem. "Prices sync at the wrong unit of measure" is a product limitation. A named record points at your item master.
Does it fail the same way every time, or only after a release? A defect that appeared after an ERP or platform upgrade is a version problem, and version problems get fixed by the vendor more often than teams expect. Acumatica’s BigCommerce sales price sync used the base unit rather than the sales unit for years, was patched with a customisation package, and then landed in the core product at 22R2.
Is the destination capable of holding the thing you are sending? If Shopify supports three product options and your template item has four, no connector on earth will fix that. That is a platform ceiling wearing a connector error’s clothes.
Does the vendor acknowledge it as a defect? On the missing matrix items thread in Acumatica’s own community, support concluded "it needs a bug fix in th Shopify connector" and the user reported that deleting and saving the sync record helped but "the error often comes back". An acknowledged open defect is a waiting problem, not a buying problem.
Is the fix a documented customisation? On the variant ordering thread, an Acumatica employee said the connector sorts variants by Option1, then Option2, then Option3, and that preserving your own order requires overriding MapVariantPositions in the SPTemplateItemProcessor graph. That is a scoped piece of work with a known shape, and it is nothing like a replatform.
Checked against: Acumatica community 6697: BigCommerce sales price sync with wrong UOM, fixed in core at 22R2, Acumatica community 20979: missing matrix items, escalated for a connector bug fix, Acumatica community 22934: variant order overwritten, resolved by overriding MapVariantPositions, Acumatica community 18873: Shopify supports only up to 3 product options
What does each diagnosis actually cost you?
The table below is the decision, stated as a table because it is a decision with four outcomes and not a spectrum. Every example in it is a real, cited Acumatica connector behaviour, because a generic version of this table would be worthless.
Read the right-hand column first. If the honest answer to "what would replacing the platform fix" is "nothing", you have your answer and you did not need the rest of the page.
| Criterion | What you see | The real fix | Would replatforming fix it? |
|---|---|---|---|
| Data defectThis is the most common diagnosis and the cheapest fix. It is also the one nobody wants to hear. | Named records fail. Duplicate attribute descriptions, items without a SKU, an inactive stock item on a price list. | Clean the item master. On Acumatica 25R1, template sync fails with "At least one option value is duplicated" if any attribute has duplicate descriptions, even ones the item does not use. | No. The new platform gets the same data and produces a different error message. |
| Version defect | It worked, then an upgrade broke it. Access scopes go missing, a sync starts failing on records it used to handle. | Reinstall or reauthorise, then wait for or apply the vendor fix. Acumatica users hitting a paymentTerms access-scope error on 25R1 resolved it by reinstalling the public app. | No, and it would introduce a fresh set of version defects on a platform you do not know yet. |
| Connector gap | A behaviour you need is not in the connector and never was. Effective sales price, variant order, a field that does not map. | A customisation, a middleware layer, or a different connector. Scoped work with a known shape. | Sometimes, if a different platform has a connector that covers the gap. Verify that before you move, not after. |
| Platform ceilingIf you are here, the connector was never the problem and replacing it will waste a year. | The destination cannot hold your data. Three product options, one stock number per SKU, a catalogue count limit. | Change the destination, or change your product model to fit it. | Yes. This is the only diagnosis where replatforming is the actual answer. |
Checked against: Acumatica community 30860: "At least one option value is duplicated" on 25R1 template sync, Acumatica community 31039: paymentTerms access scope error on 25R1, resolved by reinstalling the app, Acumatica community 17608: only Default Price is supported
When is the honest answer to keep both and fix the data instead?
When the errors name records. That is the tell, and it is a reliable one. A connector that reports "item MISIML failed" is doing exactly what it was built to do: refuse to send something the destination will reject. The 25R1 duplicate option value behaviour is the sharpest example we have, because Acumatica support traced it to duplicate attribute value descriptions and the connector refused the sync even when the specific item used none of the duplicated values. Strict validation reads as a broken connector and is closer to the opposite.
Fixing the data is unpopular for two reasons. It is nobody’s job, and it produces no demo. A replatform has a launch date, a design phase and something to show the board. Deduplicating four thousand attribute descriptions has none of that. It is also, in most of the projects that arrive at our door already stalled, the thing that would have worked.
Here is the test that settles it. Export the records that are failing. If more than one in twenty has a problem you can see with your own eyes, a missing SKU, a duplicate description, a blank unit of measure, an inactive item on an active price list, then you have a data project and buying software will not end it. Do that count before you talk to anybody, including us.
Checked against: Acumatica community 30860: duplicate attribute descriptions block template sync on 25R1, Cin7 Core: products without SKUs are not accepted, read 20 August 2026
What does replacing the connector cost that replacing the platform does not?
Replacing the connector keeps your storefront, your URLs, your customer logins and your order history, and changes the part your customers never see. That is why it is the smaller project on paper. What it costs instead is ownership: a A native connector is integration software published by the ERP or platform vendor themselves, configured rather than built. Acumatica ships native connectors for Shopify and BigCommerce. is somebody else’s problem when it breaks, and a custom or middleware integration is yours, at every ERP release, forever.
Acumatica ships two feature releases a year and the Commerce Connector changes in most of them. A native connector absorbs that. A custom one does not, and the recurring cost of keeping it current is the number most teams leave out of the comparison entirely. Budget it as an annual line, not as a project.
Replacing the platform costs the customer-visible things. Logins, saved lists, Punchout is a way for a buyer to shop on a supplier’s website from inside their own procurement system. The buyer clicks out, builds a cart, and the cart is returned to their system as a requisition for approval. endpoints your buyers point at, the redirect map for whatever part of your catalogue is public. Those are the items that generate phone calls in week one, and they are the reason a replatform feels like a much bigger event than its build hours suggest.
Checked against: Acumatica community 22934: connector behaviour changed across 2023 R1 and 24R1
Who should replace the platform, and be quick about it?
You should replatform when the destination cannot hold the shape of your product data and no amount of integration work will change that. Two concrete cases. If your template items need more than three variant axes and your storefront is Shopify, you are permanently splitting items into separate templates to fit a ceiling that is not going to move: Acumatica’s own error text says "Shopify supports only up to 3 product options", and the workaround in the thread was to break one product into two templates.
The second case is one stock number. If you sell from multiple warehouses and your platform holds a single availability figure per SKU, every branch-level promise you make is a guess dressed as a fact. That is a modelling limit, not a sync defect, and it is worth a platform change.
You should not replatform because the connector broke after an upgrade, because a field does not map, or because somebody has run out of patience. Those are the three reasons we hear most often and none of them survives the five questions above. If you have run them and you still cannot tell which layer is broken, that is a reasonable place to want a second opinion, and it is exactly what the diagnostic works out from your pricing, your catalogue shape and your ERP.
Checked against: Acumatica community 18873: "Shopify supports only up to 3 product options"
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Our connector broke after an ERP upgrade. Does that mean we should replatform?
- Almost never. A defect that appears at an upgrade is a version problem, and version problems get fixed. Acumatica users hitting an access-scope error on 25R1 fixed it by reinstalling the public Shopify app, and the BigCommerce sales unit pricing gap that needed a customisation package for years landed in the core product at 22R2. Check the vendor community for your exact release before you price a migration.
- How do we tell a connector defect from a data problem?
- Look at whether the error names a record or a rule. Named records point at your item master: missing SKUs, duplicate attribute descriptions, inactive items on an active price list. Rules that fail identically for every record point at the connector or at the platform. Export the failing records and count how many have a visible data problem. Above one in twenty and you have a data project.
- Is a custom connector cheaper than replatforming?
- To build, usually. To own, often not. A native connector is maintained by the vendor across every release; a custom one is maintained by you, and Acumatica ships two feature releases a year with connector changes in most of them. Compare them as three-year totals with an annual maintenance line, not as two build quotes.
- What are the signs that the platform itself is the problem?
- The failures are about shape rather than about records. You cannot express your product structure inside the platform’s ceilings, such as more than three variant axes on Shopify, or you cannot hold more than one availability number per SKU when you ship from several warehouses. Those limits do not move for any connector, so they are the one diagnosis where replatforming is the real fix.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.