What actually has to be decided before ERP go-live?
Seven decisions. Each one is cheap to make now and expensive to reverse after you have transacted, because reversing it means changing data that orders, invoices and history already point at. None of them requires you to have chosen a commerce platform, which is the objection you will hear and it is not a good one.
Read the reversal cost column first. That is the column that tells your VAR and your steering committee why this cannot wait, and it is the only argument that works when the go-live date is fixed.
If you only have one meeting, spend it on the first two rows. Item identity and unit of measure are the two that quietly poison every later integration, and they are the two that look like technical trivia in a project plan.
| Criterion | The decision | What it costs to reverse later |
|---|---|---|
| 1. Item identity | Which field is the public, customer-facing product code: the inventory identifier or an alternate identifier, and what is its format. | Every order, quote and cross-reference already points at the old code. Changing it later means a mapping table that lives forever. |
| 2. Unit of measure | For every item, the base unit, the sales unit, and whether the price is held against one or the other. | Reprice and republish the whole catalogue, and reconcile history that was recorded in the other unit. This is the one that produces prices wrong by a factor of twelve. |
| 3. Customer master shapeThe shape of your customer master decides whether company accounts on a storefront are a configuration or a project. | One record per buying entity or per ship-to location, where contacts live, and which record a web login will attach to. | Merging or splitting customer records after transactions exist means moving accounts receivable history. Nobody enjoys this and it never gets scheduled. |
| 4. Where price is calculated | Whether the effective price comes from a worksheet, from published price lists, or from a call to the ERP at the moment a page renders. | Restructuring negotiated prices after they are in use means re-agreeing them internally and re-testing every account. Months, not weeks. |
| 5. Warehouse and location naming | What each warehouse is called, which are sellable online, and how they will map to storefront locations. | Acumatica community 6261 documents the trouble in changing a warehouse-to-location mapping after items have already been exported. Decide the model before you publish. |
| 6. Tax ownership | Which system calculates tax for web orders, and where exemption certificates live. | Changing tax ownership after go-live means a reconciliation exercise your controller has to sign, and possibly a restatement. |
| 7. Product structure for variants | How configurable products are modelled, how many attributes each has, and whether they exceed the storefront’s ceiling. | Acumatica template item sync fails at more than three product options on Shopify, so a four-attribute product structure has to be redesigned rather than mapped. |
Checked against: Acumatica community 6261: changing warehouse to location mapping after export, Acumatica community 18873: template item sync, Shopify supports only up to 3 product options, Acumatica community 12444: Shopify sales unit and base unit
What can you honestly defer?
This is the list nobody writes down, and it is the one that gets a panicking steering committee back to work. Everything here can be added after ERP go-live without reworking ERP data, which means it belongs in a later phase and can be argued about later.
Deferring is not the same as ignoring. Write each of these down as a known future phase with a rough shape, because the difference between a deferred decision and a forgotten one is a single paragraph in the project record.
One exception to flag now. If a named customer has given you a written deadline for punchout or EDI, that is not deferrable and it should be treated as a dated commitment with its own owner, regardless of what phase the storefront is in.
Product content, images, descriptions and marketing copy. This is real work and it is not an ERP decision.
Search, merchandising, categories and navigation. All storefront-side and all reversible.
Quotes and approval workflows. They need the customer master shape to be right, which is already on the list above, and nothing else from the ERP project.
Multi-language content, unless your item descriptions themselves must be bilingual in the ERP, in which case it moves up.
Payment methods beyond terms and a single card option.
Second brands, second stores and second regions. Real work, entirely deferrable, and the wrong thing to try to anticipate now.
Customer-facing order history and invoice copies. These need data that already exists rather than decisions that have to be made.
Punchout and EDI, unless a named customer has given you a date in writing.
What do you ask your VAR this week?
Five questions, in an email, with a request for written answers. The written part matters: a verbal reassurance about the connector is exactly the thing that turns into a dispute in month eight.
A good VAR will welcome these because they narrow their own risk. A VAR who is uncomfortable with question two is telling you something useful for free.
Which of the seven decisions above have already been made in our configuration, and where is each one recorded?
Which entity will carry the price our top ten accounts pay, and have you seen it work on our data rather than in a demo?
What did you assume about our unit of measure setup, and which items have a sales unit different from the base unit?
What in the current configuration would have to change if we added a storefront in nine months, and what would that cost?
Who owns the commerce scope in this project plan, by name, and if the answer is nobody, can we add a line for it now?
Checked against: Acumatica commerce connectors, product page, read 20 August 2026
Should you delay the ERP go-live?
Almost never, and anyone who tells you otherwise is selling something. The seven decisions above take days of the right people’s attention, not weeks of project time, and none of them requires a platform choice, a budget or a vendor.
What you should refuse is the version of this conversation that expands into a full commerce discovery three weeks before go-live. That is how a date slips for a project that was going to be fine. Make the seven decisions, write them down, and let the ERP land.
There is one case for delay: if the ERP configuration has already committed to something on the list in a way you know is wrong for the business, such as a customer master shaped per ship-to when your customers buy centrally, then fixing it before transactions exist is genuinely cheaper than fixing it after. Even then the delay is measured in weeks and the fix is a data decision rather than a project.
Is the honest answer to do nothing about commerce this year?
Sometimes, and it is worth saying because nobody selling a commerce project will say it to you.
The months after an ERP go-live are not a normal operating period. Your team is learning a new system, your data is settling, your reports are being rebuilt, and your order desk is slower than it was. Starting a commerce project into that is how both projects get blamed for each other. A stabilisation period of six to nine months before commerce discovery is a defensible plan, and it costs you nothing if you have made the seven decisions.
Two conditions change that. A named customer with a written deadline is a commitment, not a preference, and it does not wait for stabilisation. And a business already losing orders to a competitor’s portal is paying for the delay in a currency that does not appear on the project budget.
If neither applies, make the seven decisions, write the deferred list into the project record with a review date, and go and land your ERP.
The wider picture
This page answers one narrow question. Acro Commerce covers the strategy around it.
Common questions
- Can we add a storefront after go-live without rework?
- Yes, if seven decisions were made before go-live: item identity, unit of measure, customer master shape, where price is calculated, warehouse naming and mapping, tax ownership, and product structure for variants. Those seven are the ones whose reversal means changing data that orders and invoices already reference. Everything else on a commerce project, including content, search, quotes, payments and additional stores, can be added later at normal cost.
- Our VAR says the connector handles all of this. Is that enough?
- No, and get the specifics in writing rather than treating that as reassurance. Ask which entity carries the price your top ten accounts pay, and ask whether they have seen it work against your data rather than in a demo tenant. Acumatica’s own community, answering a direct question about syncing the current effective sales price to Shopify, says only Default Price is supported, so a general statement that the connector handles pricing is not an answer to the question you asked.
- Should we delay ERP go-live to scope commerce properly?
- Almost never. The decisions that must be made before go-live take days of the right people’s attention and none of them requires a platform choice or a budget. The exception is where the ERP configuration has already committed to something you know is wrong for the business, such as a customer master shaped per ship-to when your customers buy centrally, in which case fixing it before transactions exist is cheaper than fixing it afterwards.
- How much of the commerce budget should we hold back now?
- Hold back a discovery, not a build. Booking a fixed commerce budget before you know which of the seven decisions your ERP configuration landed on produces a number that is wrong in both directions. What is worth protecting in the plan is a named owner for commerce scope and enough budget to run a proper discovery once the ERP is stable, because the discovery is what turns the platform question from an argument into an answer.
- What if go-live has already happened and none of this was decided?
- Audit the seven decisions against what the configuration actually did, and separate them into what has already been transacted against and what has not. Items with no order history can still be restructured cheaply. Customer records with accounts receivable history cannot. That split tells you which of the seven are now constraints you design around and which are still choices, and it is a far more useful starting point for a commerce project than a blank requirements document.
Last updated 2026-08-20. Facts on this page last checked against source 2026-08-20.