A new storefront is easy to celebrate. The homepage is faster. Checkout is cleaner. The demo looks like progress.
Then the first week of live orders begins.
Someone still keys orders into the ERP. Inventory is still a nightly file. Customer records still disagree across commerce, CRM, and finance. Exceptions still live in inboxes. The catalog still has one meaning on the website and another in the warehouse.
The technology changed. The company did not.
That is why so many commerce transformations stall. Leadership funded a platform decision. The business needed an operating-model decision.
What Transformation Has to Produce
A storefront is the surface customers see. Transformation has to change how work gets done behind it.
That means an order created in commerce is a trusted business event, not a ticket for someone to re-enter. Inventory, price, and customer status are consistent enough that people and systems can act without a reconciliation meeting. Workflows have owners, exception paths, and a standard way to complete the work that happens between systems. The organization can measure whether operations improved, not only whether the site launched.
Both the storefront and the operating backbone matter. Only one of them determines whether automation and AI can do useful work later.
The organizations that get this right treat connectivity as a launch requirement. The storefront becomes the visible expression of that connectivity, not a project that hopes the rest of the business will catch up.
Connect, Then Automate, Then Apply Intelligence
The useful sequence is not "select a platform, add apps, then introduce AI." It is more demanding, and more honest.
Connect the systems that already run the business. Commerce, ERP, CRM, PIM, OMS, WMS, POS, and payment systems have to exchange trusted information at the speed the process requires. Batch sync creates blind spots. Point-to-point patches create the next decade of fragility. If the same SKU, customer, or order has three meanings, every downstream tool inherits the conflict. That is an integration problem, even when it is funded as an AI initiative.
Standardize and automate the work between those systems. Order routing, inventory reservation, fulfillment triggering, returns, invoicing, and exception escalation are where teams lose time. Automation that sits on top of undocumented workarounds only makes the workaround faster.
Then apply intelligence where the process can absorb it. Demand sensing, exception triage, forecasting, and assisted selling are not products you drop onto a fragmented landscape. They are capabilities that become possible after data can be trusted and workflows can execute.
McKinsey's 2026 State of AI survey is a useful warning here, not a destination. Nearly nine in ten respondents say their organizations use AI in at least one function. Only 37 percent attribute any EBIT impact to it, and the share of high performers — those reporting at least 5 percent EBIT impact and significant value — remains about 6 percent. High performers are far more likely to redesign workflows than to insert AI into the ones they already have.
That finding matches the pattern in commerce programs. AI does not rescue a transformation that left operations untouched. It makes the gaps more expensive. Why most AI projects fail before they begin is the same argument from the other side: the model is not the first constraint.
Why "Phase Two" Integration Rarely Arrives
The most common plan is still sequential: launch the storefront, then integrate, then automate, then consider AI.
Phase two is where the hard operational work is parked. It is also where budget, attention, and executive patience usually run out. The site is live. The vendor story has been written. The team is already supporting the new front end. Back-office work starts to look like maintenance, even when it is the actual transformation.
The result is a modern buying experience attached to the same operating constraints:
- Available-to-promise that cannot be trusted
- Pricing that has to be checked by a person
- Fulfillment that depends on tribal knowledge
- Customer service that logs into three systems to answer one question
- Finance that spends close cycles matching records that should have been the same event
This is not a technology failure. It is a sequencing failure. Integration planned after launch is treated as optional. Optional work does not survive contact with a live operation.
McKinsey has made a related point about AI programs: adoption often fails because adjacent upstream and downstream processes are left unchanged. Commerce replatforming fails the same way. The buying path moves. Order entry, inventory, and exception handling do not.
How to Tell a Platform Project from an Operating-Model Project
A platform project asks: which storefront should we buy, and when can it go live?
An operating-model project asks: what has to be true about orders, inventory, customers, and exceptions on the day we launch — and who owns those outcomes after go-live?
The difference shows up in the deliverables.
If success is a migrated catalog, a new theme, and a cutover date, you are running a platform project. That work can still be necessary. It is not sufficient.
If success is orders flowing into the system of record without re-keying, inventory remaining accurate across channels, and exceptions routing to the right owner with an audit trail, you are running a transformation.
One practical test: if the AI or automation use cases on the roadmap would fail today because the data is late, incomplete, or untrusted, those use cases are not future phases. They are evidence that the current design is unfinished.
Another test: when two systems disagree, is there a decided system of record, or a meeting? Transformation requires the former.
A Sequence Leadership Can Actually Run
The work is not mysterious. It is easy to skip.
Start with the operating picture, not the demo. Map how an order, a price, a customer update, and an inventory movement actually travel today. Name the handoffs, the files, the inboxes, and the people who keep the process working. Most failed programs compress this step because it does not look like progress. It is the only way to know what launch must include.
Put connectivity on the critical path. ERP integration, inventory synchronization, order orchestration, and fulfillment status should be live with the storefront, not promised afterward. If a dependency cannot be ready, narrow the launch. Do not pretend the gap is temporary.
Choose a small number of operational outcomes. Faster quote-to-order, fewer oversells, less manual order entry, cleaner invoice matching, or more reliable pickup are outcomes. "More AI" is not. The first initiatives should matter commercially and be constrained enough to finish.
Assign owners who can change the process. A commerce platform vendor cannot redesign how finance recognizes an order or how the warehouse releases inventory. Someone inside the business has to own the workflow, including exceptions.
Treat post-launch as part of the transformation. The operating model is not finished at cutover. It has to be watched, corrected, and improved. That requires the same integration and data discipline you built to launch — not a return to spreadsheet workarounds.
A readiness view of systems, data, workflows, and governance is a better starting document than a platform scorecard. Arizon Digital uses that lens in the Agentic Commerce Readiness Index when organizations want a clear picture of what is actually prepared for automation and AI. The assessment is not the transformation. It is a way to stop funding the next tool before the foundation can support it.
The Storefront Is Not the Company
Buyer expectations for speed, accuracy, and reliability will not ease. Competitors that can promise availability, honor price, and complete an order without a back-office scramble will keep setting the standard.
A capable commerce platform is part of the answer. It is not the answer. The right platform on a fragmented operating model still produces fragmented results.
Transformation is the decision to connect the business, make the work between systems executable, and only then apply intelligence. Organizations that reverse that order usually get a nicer website and the same operational constraints they meant to leave behind.
The question for leadership is simple. If the new storefront launched on time, and orders still needed a person to finish what the systems should have finished together, did the business transform — or did it replatform?