The E-Commerce Platform Is Not the Strategy

By October 2026, this is hardly an implausible situation.

Developments in Agentic Commerce are changing how products can be discovered, offers compared and purchases prepared or completed. AI applications are emerging as another interface between customers and retailers. Businesses must consider whether their existing E-Commerce systems are equipped to participate in this evolving environment.

OpenAI's Agentic Commerce Protocol and Google's Universal Commerce Protocol provide concrete technical approaches for connecting AI applications with existing E-Commerce systems. Platform vendors are developing corresponding capabilities and integrations. Possibilities that recently belonged largely to discussions about the future of digital retail are increasingly taking the form of documented interfaces, available services and early production implementations.

The resulting pressure to act is understandable.

A business that enters emerging sales channels too late may lose valuable commercial opportunities. One that commits prematurely to a fundamental platform replacement may consume capital and organisational capacity before establishing whether the anticipated capabilities are relevant to its business model.

The uncertainty extends beyond the speed at which Agentic Commerce will develop. It concerns the technology a business genuinely needs to participate.

A newer E-Commerce platform may provide capabilities that the existing system lacks. That does not establish that replacing the platform is the only way to obtain them. Nor does earlier access to a particular capability necessarily translate into commercial advantage.

This dilemma predates Agentic Commerce.

International expansion, B2B E-Commerce, omnichannel strategies, marketplace integration and changing business models have repeatedly prompted companies to reconsider their established E-Commerce platforms. Sometimes the existing technology has indeed become a structural constraint. In other cases, the underlying difficulties have originated in system integration, business processes or the organisation responsible for operating them.

Distinguishing between these situations is the real challenge.

Replacing an E-Commerce platform is a substantial business decision. It changes more than software. It can reshape operating processes, technology dependencies, organisational responsibilities and the economic options available to the business for years to come.

Discovering that another platform offers a capability one's existing platform does not is therefore insufficient justification.

A business needs to understand which commercial capability it requires, what actually prevents its delivery and which intervention can resolve the problem at an acceptable cost and level of risk.

The operational capability of an E-Commerce business, however, emerges from the interaction of these systems.

Product information may be maintained in a Product Information Management system. An ERP system may govern financial processes and essential master data. An Order Management System coordinates order fulfilment. Other systems support customer relationships, payments, logistics and physical retail operations.

There is no universally correct boundary between the responsibilities of the E-Commerce platform and those of the surrounding systems.

A mid-sized retailer operating a single online shop may benefit from a largely standardised solution that incorporates most of the required capabilities. An international retail group with several brands, sales channels and legal entities may require a considerably more distributed architecture.

B2B E-Commerce frequently adds further complexity. Customer-specific pricing, purchasing organisations, approval workflows, contractual terms and sophisticated ordering processes can materially influence the appropriate architecture.

The architecture should follow the business model and its operating requirements. Its quality cannot be established by counting features or examining the apparent modernity of its individual components.

The same principle applies to the promise of an integrated software suite.

A single vendor can offer genuine advantages. Coordinated product development, consistent support arrangements, common commercial relationships and prepared integrations may simplify operations. What matters, however, is the extent of integration actually delivered.

A common brand does not guarantee a common data model. Neither does it establish that customer identities, prices, inventory and orders are processed consistently across every component.

Extensive software portfolios may include products originally developed independently of one another. Their technical and operational integration must be examined in the context of the intended implementation.

An architecture assembled from specialised systems introduces a different set of responsibilities. Interfaces must be maintained, changes coordinated and ownership clearly established. Independence between components can create substantial business value, but only where the organisation can manage the resulting complexity.

Choosing between an integrated suite and a more modular E-Commerce architecture is consequently not a straightforward choice between convenience and flexibility.

It is a decision about the distribution of technological and organisational responsibility.

Which business processes need to operate consistently across the organisation? Where does the business require individual freedom of design? Which dependencies can it reasonably accept? And which decisions must remain under its own long-term control?

These questions provide a more meaningful basis for evaluating an E-Commerce platform than a catalogue of available features.

New features take too long to deliver. Connecting another sales channel proves unexpectedly complicated. Inventory information is inconsistent. Custom development becomes progressively more expensive. Introducing a new business model requires an increasing number of workarounds.

These difficulties may indicate structural limitations in the existing E-Commerce platform. They may equally originate elsewhere in the technology landscape.

Consider a retailer that wants customers to place an order online and collect the goods from a physical store.

At first glance, the requirement appears relatively simple. The online shop needs an appropriate delivery option and a way of displaying whether a product is available at a particular location.

That does not mean the business process has been solved.

The availability displayed must be current and sufficiently reliable. An item reserved for collection should not simultaneously disappear into a conventional in-store transaction. The systems must distinguish between an order being prepared, confirmed, ready for collection and completed. Store employees need the relevant information, and cancellations and returns must be handled appropriately.

Whether this process works depends on considerably more than the E-Commerce platform.

The actual limitation may be found in inventory management, stock reservation, order orchestration, point-of-sale systems or coordination between the departments involved.

A new platform with an impressive click-and-collect feature will not automatically solve those problems. It may provide a suitable customer interface and prepared integrations, but it will still depend on accurate information and functioning operational processes.

There is, of course, an important counterexample.

If the existing E-Commerce platform cannot adequately represent essential order states, can support necessary processes only through fragile customisation or structurally prevents reliable integration, the platform itself may have become the constraint.

The difficulty is then not confined to the surrounding architecture. The platform restricts a business capability that the organisation genuinely requires.

This distinction is central to a credible diagnosis.

It becomes particularly important in Unified Commerce. The ambition to provide customers with consistent information and processes across online shops, stores, marketplaces and other sales channels demands considerably more than connecting systems through technical interfaces.

Customers expect accurate product availability, reliable order information and customer service that understands their transactions. Whether those capabilities are delivered through one central platform or several specialised systems is largely irrelevant to them.

For the business, the underlying architecture matters enormously.

It must establish which system is authoritative for particular information, how changes are propagated and how errors can be detected and corrected. An interface can function technically while still supplying information that is inadequate for the intended business process.

The existence of an API does not establish end-to-end operational capability.

Another frequently underestimated problem is the accumulation of technical debt between systems rather than within the E-Commerce platform itself.

Historical integrations, duplicated data, customised pricing rules and poorly documented dependencies can make further development increasingly difficult. Many of these arrangements originated from entirely reasonable business requirements. They become problematic when their original assumptions no longer apply or their consequences are no longer properly understood.

Replacing an E-Commerce platform does not automatically eliminate those dependencies.

The replacement still needs accurate prices, reliable inventory information and functioning business rules. Where the origin or ownership of that information remains unclear, the uncertainty is carried into the new architecture.

A proper diagnosis must therefore distinguish between limitations attributable to the existing E-Commerce platform and problems that would survive its replacement.

Only then can management determine whether replacing the platform is necessary or whether it would merely exchange the most visible component of a fundamentally troubled architecture.

Customers can research products through AI applications, compare alternatives and receive assistance with their purchasing decisions. Under certain conditions, these applications can prepare shopping baskets or participate in checkout processes. More advanced models allow AI agents to perform defined actions on behalf of a customer within explicitly granted permissions.

These capabilities differ significantly in their technological requirements and commercial implications.

AI-assisted product selection initially depends on suitable product information. Its quality, currency and structure are essential. Reliable access to pricing and availability may create additional requirements.

An agent-prepared shopping basket needs to reconcile the selected products with the rules of the existing E-Commerce platform. Completing a checkout introduces delivery options, taxation, payment processing, customer identity and order confirmation.

When agents are authorised to act within a delegated mandate, permissions, spending limits, authorisation and accountability become especially important.

Not every capability requires the same architecture. Nor does every capability offer the same value to every business.

A retailer selling products that require substantial advice may initially benefit more from AI applications understanding and recommending its assortment. A company processing standardised repeat purchases may find greater value in automating parts of the purchasing process.

These are plausible business hypotheses, not universally established market outcomes. Their relevance has to be tested against actual customer requirements and commercial opportunities.

The decision should therefore not begin with the capabilities offered by another E-Commerce platform.

It should begin with the changes in customer behaviour or business operations that the company considers relevant, followed by an assessment of the specific capabilities those changes require.

Only then does the suitability of the existing E-Commerce architecture become the central question.

Recent developments show that replacing the platform is not necessarily a prerequisite.

OpenAI's Agentic Commerce Protocol describes an integration model in which merchants retain responsibility for essential checkout and order processes within their existing infrastructure. The merchant validates the order, calculates relevant amounts and processes payments through its established payment service providers.

Google's Universal Commerce Protocol distinguishes, among other approaches, between direct checkout within supported Google experiences and the transfer of a prepared shopping basket to the merchant's own online shop.

The two approaches differ in their technical requirements and access conditions. Both nevertheless demonstrate that agentic purchasing experiences can connect with existing E-Commerce systems without necessarily replacing their underlying transaction processing.

Shopify provides another illustration.

Shopify's Agentic Plan also addresses merchants that operate their existing E-Commerce platform with another provider but want to participate in selected agentic sales opportunities. Depending on the supported channel, the transaction may continue through the merchant's existing online shop or a checkout capability provided by Shopify.

This creates an additional option between declining to adopt new capabilities and replacing an entire E-Commerce platform.

It should not, however, be mistaken for independent evidence of commercial suitability. The proposition comes from a vendor's documented offering. Its actual costs, integration requirements, restrictions and commercial implications still require individual examination.

Nor are the emerging protocols and services universally available. A published specification, an approved partner programme, a pilot implementation and a generally accessible production capability are not interchangeable.

As at the research date, Instant Checkout in ChatGPT remains restricted to approved partners. Access to certain UCP capabilities within Google's own AI experiences also requires the relevant approval.

Businesses should be cautious about making platform commitments on the strength of capabilities that have been announced but are not yet available to them.

The economic consequences of new intermediaries between retailers and their customers deserve equal attention.

An additional sales channel may provide access to new audiences and purchasing journeys. It may also introduce dependencies concerning visibility, customer access, transaction conditions and the information available to the merchant.

The ability to sell products through an AI agent says little, on its own, about the commercial terms under which those transactions will take place.

This changes the appropriate measure of an E-Commerce platform's suitability.

The decisive issue is not whether the platform incorporates every new agentic feature itself. It is whether the platform and its surrounding architecture can provide the relevant product information, business rules and transaction processes reliably and under appropriate control to the applications the business intends to use.

Where that can be achieved through proportionate integration, retaining the existing platform may be entirely consistent with the company's strategy.

Where fundamental platform limitations prevent capabilities on which a future business model depends, the decision takes on a different character.

Agentic Commerce then becomes potential evidence of a genuine strategic constraint rather than simply another reason to seek more modern technology.

A business may select a technically capable architecture and still struggle because essential decisions, responsibilities or competencies are insufficiently defined.

This is particularly relevant to highly modular E-Commerce architectures.

The ability to choose, replace and develop individual capabilities independently can deliver considerable advantages. Businesses can create differentiated solutions where their commercial model demands greater freedom of design.

That freedom also creates responsibility.

Interfaces need to be developed and monitored. Changes to one component can affect others. Data ownership, security requirements, release processes and error handling must work across the architecture rather than within individual applications alone.

A company does not necessarily need a large internal development department to manage these responsibilities. Neither must it operate every system itself.

It does need to understand and exercise appropriate control over essential architectural decisions, the dependencies those decisions create and the people responsible for their consequences.

The distinction matters particularly where external implementation partners perform much of the technical work.

A specialist partner may contribute valuable expertise and accelerate delivery considerably. The relationship becomes problematic when the business can no longer evaluate essential decisions independently or when continued operation depends on specialised knowledge held by individuals who are difficult to replace.

The organisation may then possess a technically flexible architecture without enjoying equivalent strategic freedom.

A more standardised SaaS platform can offer advantages in such circumstances. The vendor assumes responsibility for significant operational functions, provides defined capabilities and develops them within a shared product model.

This reduces some forms of technological responsibility while introducing different dependencies.

Individual business requirements must fit within the permitted configuration, extension and integration mechanisms. The vendor determines substantial elements of product development and the technical boundaries within which customers can operate.

Where a strategically necessary capability falls outside those boundaries, a seemingly simple architecture can gradually acquire an expensive collection of additional solutions.

Neither technological flexibility nor extensive standardisation should therefore be treated as a measure of quality in isolation.

The appropriate choice depends on the business model, the freedom of technological design it actually needs and the responsibilities the organisation can sustain.

Research by the MIT Center for Information Systems Research explicitly connects enterprise architecture with a company's operating model. The requirements for integration and standardisation across business processes are central to that relationship.

The implications for E-Commerce platform decisions are substantial.

An architecture should do more than make a particular technical solution possible. It needs to fit the company's responsibilities, capabilities and decision-making processes.

Those conditions may themselves change.

A business expanding internationally may need a different approach to architectural governance from the one that served it during an earlier stage of growth. A developing B2B business may introduce new requirements for pricing, customer structures and order processing. A serious omnichannel strategy may require departments that previously operated independently to assume shared responsibility for customer-facing processes.

Such developments can justify changing the E-Commerce platform. They can also reveal organisational capabilities that must be established before any replacement platform can deliver its anticipated benefits.

A technically superior platform offers limited value if its advantages depend on operating conditions the business cannot realistically sustain.

Licence fees, hosting, maintenance and ongoing service costs are important considerations. They are not sufficient to justify a decision of this magnitude.

A complete platform replacement involves expenditure on solution design, implementation, data migration, integration, testing and changes to existing business processes. New service agreements, training, organisational adjustments and periods of parallel operation may add substantially to the investment.

Transferring historically developed business logic can be especially demanding.

Some functions are properly documented and straightforward to understand. Others consist of numerous exceptions whose original purpose becomes clear only during the migration.

At that point, the business needs to decide which of those functions are still necessary and which have survived primarily through habit.

Recreating every existing exception without examination risks reproducing old complexity within a new technological environment.

Redesigning established processes, on the other hand, introduces additional commercial and organisational consequences that must also be considered.

A comparison between two E-Commerce platforms is therefore insufficient.

What matters economically is the future effect of the alternatives genuinely available to the business.

In many situations, three broad options merit consideration.

The business can retain and selectively improve its existing E-Commerce platform. It can modernise or extend particular parts of its E-Commerce architecture. Or it can replace the platform in its entirety.

These options are not necessarily equally suitable. They should nevertheless be assessed using assumptions that are transparent and sufficiently comparable.

A common evaluation period is essential. A substantial initial investment followed by lower operating costs cannot sensibly be compared with a solution that is inexpensive in the short term but becomes significantly more costly over several years.

Expected commercial outcomes also matter.

A new E-Commerce platform may reduce development lead times, enable additional business models or mitigate operational risks. Such benefits have economic value. Their scale and likelihood should not be derived solely from a vendor's promises.

The point at which the benefits become available is equally significant.

A targeted modernisation may deliver initial results within a few months. A full platform replacement may require a considerably longer period during which the existing system must continue operating.

Throughout that transition, the company commits capital, management attention and operational expertise.

Those resources cannot simultaneously be applied to other opportunities without constraint.

The economic analysis therefore needs to consider both Total Cost of Ownership and Total Cost of Change.

In this essay, Total Cost of Change provides an analytical framework for examining the full economic consequences of a proposed transformation. Beyond investment and operating expenditure, it includes transitional costs, organisational demands, risks, opportunity costs and enduring new dependencies. It is not presented as a universally standardised calculation method for E-Commerce platform replacements.

The same analytical discipline should be applied to the option of retaining the existing system.

An established platform may incur increasing maintenance costs. Missing capabilities may delay new business models. Security concerns, declining support or specialist skills that have become difficult to obtain can create substantial future liabilities.

Keeping the existing E-Commerce platform is not necessarily the economically conservative option.

Past investment, meanwhile, is not an independent justification for continuing with an unsuitable system. The amount already spent is less relevant than the future costs, risks and benefits associated with the alternatives.

A gradual modernisation is frequently among those alternatives.

The established Strangler Fig approach to software architecture describes the progressive replacement of existing functions with new components. This allows a business to limit the scope of individual changes and potentially realise benefits before the entire legacy system has been retired.

The approach also requires transitional arrangements. Running old and new components alongside one another creates temporary integrations and additional operational demands. Reducing the risk of a single major change does not automatically minimise total expenditure.

The economic decision consequently extends far beyond choosing between old and new software.

Management needs to establish which alternative will provide the required commercial capabilities within an appropriate period and what expenditure, risks and dependencies the company must accept in return.

Not every assumption will carry the same degree of certainty.

Future demand for a new capability may remain uncertain. The actual cost of migration may become clearer only after a detailed technical assessment. Existing maintenance expenditure or documented security weaknesses, by contrast, may already be well understood.

Those differences should remain visible in the decision.

A credible platform decision does not require artificial certainty about the future. It requires a disciplined distinction between established facts, reasonable assumptions and material uncertainties.

That would be as unhelpful as assuming that replacement is the natural response to technological change.

There are circumstances in which replacing a platform becomes necessary or economically sensible before the existing system can no longer perform its current functions.

If support for an E-Commerce platform is approaching its end, essential security requirements can no longer be met reliably or the necessary technical expertise is becoming unavailable, the future operational risk may itself justify intervention.

A company does not need to wait for a critical business process to fail.

Structural limitations affecting future development can also justify an early decision.

Where a new business strategy depends on capabilities that the current E-Commerce platform could deliver only through disproportionate customisation, moving to a different platform may be the more responsible economic choice.

That does not mean every conceivable extension must first be implemented and proven unsuccessful.

What is needed is a sufficiently reliable assessment of the technical, economic and organisational viability of the alternatives.

Equally, a replacement platform should not be preferred merely because it already includes a particular feature.

A documented capability advantage may matter. Whether it is strategically decisive depends on how the business intends to use that capability, when it must become available and what commercial benefit it can reasonably be expected to deliver.

This brings us back to the original situation.

An E-Commerce executive observes the emerging possibilities of Agentic Commerce. Competing platform vendors demonstrate capabilities that the existing system does not yet provide.

The executive could initiate a platform selection exercise and search for the most technologically advanced alternative.

Or the business could first establish which agentic applications are relevant to its commercial model, which information and processes those applications require and whether the necessary capabilities can be delivered through the existing E-Commerce architecture.

Only when that examination reveals a material structural limitation does the platform decision acquire a different foundation.

The question is no longer whether another product appears more attractive. It becomes whether the current E-Commerce platform prevents a commercially necessary development and which alternative can overcome that limitation with commercially justifiable costs and risks.

The reasoning applies whether the immediate trigger is Agentic Commerce, international expansion, B2B growth, Unified Commerce or a more fundamental change to the business model.

An E-Commerce platform remains an important part of a company's ability to act. It influences which processes function reliably, which developments are possible and which technological dependencies arise.

But it is not a strategy in itself.

Strategy establishes the commercial capabilities a company needs and the changes it is prepared to undertake to develop them. The E-Commerce platform must be suitable for those requirements.

Sometimes that means developing the existing architecture. Sometimes it calls for the selective modernisation of particular components. And sometimes replacing the entire platform is the right decision.

The quality of that decision is not demonstrated by how modern the selected technology appears.

It is demonstrated by how convincingly the business can explain why a particular change is necessary, which alternatives have been examined and what responsibilities it accepts as a consequence.

A complementary perspective is developed in Executive Essay 03, The Architecture of Better Questions, which examines the importance of establishing the right problem before evaluating technological solutions.