When ecommerce costs become difficult to control, replatforming is often presented as the obvious solution.
A newer platform promises lower licence fees, fewer upgrades, faster releases and less technical overhead. For retailers operating complex Adobe Commerce environments, the comparison frequently points towards a SaaS platform such as Shopify Plus.
Sometimes that recommendation is correct.
But replacing the platform does not automatically remove the cost. It may simply move it—from hosting and development into applications, transaction fees, integration work, operating constraints and migration costs.
Before committing to a replatforming program, retailers need to identify what is actually creating their total cost of ownership.
The platform may be responsible. The implementation may be responsible. The surrounding architecture, delivery model or internal processes may be responsible.
Those are different problems, and they require different solutions.
What ecommerce total cost of ownership includes
Ecommerce TCO is the complete cost of operating and changing the commerce capability over a defined period, usually three to five years.
It includes much more than the platform licence.
| Cost layer | Examples |
|---|---|
| eCommerce Platform | Licences, subscriptions, hosting, infrastructure and usage fees |
| Technology ecosystem | Applications, extensions, integrations, middleware and monitoring |
| Delivery | Development, testing, releases, environments and project management |
| Operations | Catalogue administration, customer service, merchandising and manual workarounds |
| Commercial impact | Conversion, availability, performance, downtime and delayed initiatives |
| Transition | Migration, data remediation, retraining, parallel operation and implementation risk |
A platform with a higher licence cost may still produce a lower TCO if it supports important requirements without extensive additional systems.
A platform with an attractive subscription price may become expensive when the retailer adds multiple applications, rebuilds integrations and adapts business processes around platform constraints.
TCO should therefore evaluate the complete commerce operating model—not compare two platform invoices.
Separate the platform from the implementation
Retailers frequently describe a problem as an Adobe, Shopify, Salesforce or BigCommerce problem when the underlying cause is implementation-specific.
Examples include:
- An extension that has not been maintained
- Custom functionality duplicating a native capability
- A fragile ERP integration
- Inconsistent product data
- An unnecessarily complex frontend
- A slow manual testing process
- Unclear ownership between internal and agency teams
- Years of deferred upgrades
- Business rules embedded in undocumented code
- Multiple tools performing overlapping functions
Changing platforms will remove some of these problems. It may also recreate them in a new environment if the same architecture, governance and delivery habits remain.
The first objective of a TCO review should be attribution: determining where each material cost originates and whether replacing the platform would actually remove it.
1. Establish a three-to-five-year cost baseline
Retailers cannot reduce TCO reliably if ecommerce costs are spread across technology, marketing, operations, finance and agency budgets.
Begin by constructing a complete cost baseline.
Include:
- Platform licences
- Hosting and infrastructure
- Content delivery
- Applications and extensions
- Search and personalisation
- Payment costs
- Integration platforms
- Monitoring and security
- Development and support partners
- Internal technology employees
- Internal ecommerce operations
- Quality assurance
- Release management
- Product-data administration
- Customer-service workarounds
- Incident response
- Downtime and performance issues
Separate expenditure into three categories:
Run
The cost of keeping the current operation available, secure and supported.
Change
The cost of delivering enhancements, integrations, campaigns and new capabilities.
Failure demand
The cost created because something does not work correctly or efficiently.
Failure demand can include repeated customer enquiries, manual order correction, catalogue remediation, failed deployments and emergency support.
This distinction matters. A retailer may appear to have a high support cost when much of the expenditure is repeatedly correcting a small number of structural problems.
A useful baseline should also show cost by business capability. For example:
- Cost per release
- Cost per integration
- Cost per product onboarded
- Cost per supported market
- Cost per order
- Cost per customer-service interaction
- Cost per million dollars of revenue
This makes the model useful for operational decisions rather than merely producing a large annual total.
2. Rationalise customisation
Customisation is one of the largest sources of avoidable ecommerce TCO.
That does not mean customisation is inherently wrong.
A retailer may have genuinely differentiating requirements involving:
- Complex product configuration
- Trade pricing
- Account hierarchies
- Customer-specific catalogues
- Store or franchise ownership
- Regulated products
- Distributed inventory
- Specialised fulfilment
- Approval workflows
- Unique loyalty propositions
Custom functionality can be commercially valuable when it supports an important customer need or operating advantage.
The problem is customisation without continuing economic justification.
Every significant customisation should be classified as:
- Differentiating: It creates a meaningful customer or commercial advantage.
- Operationally necessary: It supports a requirement the platform cannot meet acceptably.
- Historical: It solved a previous requirement that may no longer exist.
- Duplicative: The current platform or another system now provides the capability.
- Preferential: It reflects a desired way of working rather than a material requirement.
Historical, duplicative and low-value preferential customisations should be candidates for removal.
This reduces more than code volume. It can lower testing, upgrade, security and support costs while increasing release speed.
The financial question is:
Does the ongoing commercial value of this customisation exceed its maintenance cost and the complexity it adds to every future change?
If the answer cannot be demonstrated, it should not remain protected simply because it already exists.
3. Reduce extension and application overlap
Commerce environments often accumulate extensions and applications one business request at a time.
A retailer may have separate tools for:
- Search
- Product recommendations
- Personalisation
- Reviews
- Promotions
- Loyalty
- Fraud
- Analytics
- Tag management
- Customer service
- Merchandising
- Content
- Feed management
- Product information
- Delivery estimates
Each addition may have been reasonable when approved. Collectively, they can create a costly and fragile ecosystem.
The cost is not limited to subscriptions.
Each tool may also introduce:
- Integration work
- Data duplication
- Page-performance overhead
- Security assessment
- Privacy obligations
- Regression testing
- Internal training
- Vendor management
- Release coordination
- Exit costs
Create an application register that records:
- Annual licence cost
- Business owner
- Technical owner
- Primary capability
- Overlapping capabilities
- Revenue or operational contribution
- Integration dependencies
- Performance impact
- Contract renewal date
- Replacement difficulty
Applications should then be classified as retain, consolidate, replace or retire.
This exercise applies equally to Adobe Commerce and SaaS platforms. Adobe implementations may accumulate extensions and bespoke modules; Shopify implementations may accumulate applications and recurring service fees.
Different platforms change the form of ecosystem cost. They do not eliminate the need for governance.
4. Address version and upgrade debt
Deferred platform upgrades can make an existing platform appear structurally more expensive than it needs to be.
When a retailer falls behind supported versions:
- Security work becomes more urgent.
- Extensions become incompatible.
- Changes require more regression testing.
- Developers spend more time working around outdated components.
- Future upgrades become larger and riskier.
- Platform support may become constrained.
- New native capabilities cannot be adopted.
Adobe’s own TCO guidance identifies keeping Commerce current as one way to control ownership cost. While vendor material should not be treated as independent analysis, the underlying principle is sound: deferred maintenance compounds.
Retailers should compare three scenarios:
- Continue supporting the current version.
- Upgrade and simplify the existing implementation.
- Replace the platform.
The upgrade scenario should not assume that every legacy customisation must be carried forward. An upgrade can be used as a controlled simplification program.
In some cases, modernising the existing platform removes enough technical debt to change the replatforming business case substantially.
5. Simplify integration architecture
The commerce platform is often blamed for costs generated at its boundaries.
Complex retail environments may connect ecommerce with:
- ERP
- Point of sale
- Product information management
- Order management
- Warehouse management
- Customer relationship management
- Loyalty
- Payments
- Tax
- Fraud
- Search
- Marketing
- Delivery providers
- Marketplaces
- Supplier systems
Costs increase when these connections are point-to-point, poorly monitored or dependent on undocumented transformations.
Common symptoms include:
- The same data transformed multiple times
- Batch updates that create availability delays
- Manual reconciliation
- Integration failures discovered by customers
- Business rules duplicated across systems
- Changes requiring coordination across several vendors
- No clear authoritative source for important data
- Excessive movement of data that is not used
Integration simplification does not necessarily require a major composable architecture program.
Quick improvements may include:
- Defining systems of record
- Removing duplicate feeds
- Consolidating transformations
- Improving error handling
- Adding meaningful monitoring
- Documenting data contracts
- Decoupling high-change components
- Retiring obsolete endpoints
- Reducing unnecessary synchronisation
The cost of an integration should include the effort required to operate, monitor and change it—not only the original build.
Replatforming without resolving integration ownership may result in the same complexity being rebuilt around a different commerce engine.
6. Reduce the cost and risk of every release
A platform’s TCO is heavily influenced by the cost of changing it.
If a minor customer-experience improvement requires weeks of coordination, manual testing and production support, the retailer pays more for every initiative.
Release cost can be driven by:
- Large deployment batches
- Manual regression testing
- Unstable environments
- Poor automated coverage
- Shared test data
- Long approval chains
- Unclear requirements
- Agency handoffs
- Fragile customisations
- Limited rollback capability
- Inadequate observability
Measure:
- Lead time from approval to production
- Development effort
- Testing effort
- Deployment effort
- Failure rate
- Rollback frequency
- Production incidents
- Time to restore service
- Number of teams involved
The objective is not simply to release more frequently. It is to reduce the cost and risk of moving a valuable change into production.
Potential improvements include:
- Automated regression coverage for critical journeys
- Smaller releases
- Reusable components
- Stable development environments
- Better acceptance criteria
- Feature flags
- Automated deployment
- Clear rollback procedures
- Improved monitoring
- Defined release ownership
These changes can reduce TCO regardless of platform.
A SaaS platform may remove some infrastructure and upgrade responsibilities, but it does not automatically fix requirements quality, testing discipline, integration coordination or organisational approval processes.
7. Right-size hosting and infrastructure
Infrastructure costs can become detached from actual demand.
Retailers may continue paying for capacity designed around historical peaks, previous architectures or outdated assumptions. Cloud environments may also accumulate unused services, excessive data retention and inefficient non-production resources.
Review:
- Peak and baseline utilisation
- Autoscaling configuration
- Database consumption
- Search infrastructure
- Content delivery
- Image processing
- Logging volume
- Data-transfer costs
- Development and testing environments
- Backup and retention policies
- Disaster-recovery arrangements
- Third-party observability platforms
Cost reduction should not compromise resilience or peak trading.
Retailers need to distinguish between excess capacity and necessary commercial protection. Infrastructure that appears unused during normal trading may be essential during major campaigns.
The correct objective is efficient resilience.
This is one area where platform models differ materially.
A SaaS platform may bundle hosting, security and upgrades into its commercial model. Adobe Commerce may give the retailer greater architectural control while creating more responsibility for implementation and operations.
Neither model is inherently cheaper in every situation. The answer depends on traffic, transaction volume, performance requirements, customisation and internal capability.
8. Improve product and content operations
Some ecommerce TCO is hidden in manual business processes rather than technology budgets.
Retail teams may spend substantial time:
- Cleaning supplier data
- Correcting product classifications
- Resizing images
- Re-entering promotional information
- Managing spreadsheets
- Checking catalogue errors
- Republishing similar content
- Correcting marketplace feeds
- Responding to product questions
- Managing attributes in several systems
This work can become normalised because it is distributed across several employees and departments.
Map the operational steps required to:
- Launch a new product
- Update a price
- Create a promotion
- Open a new category
- Add a market
- Change delivery eligibility
- Publish a campaign
- Correct inaccurate product data
Record the elapsed time, manual effort, handoffs and failure points.
The solution may involve better workflow, structured data, system integration, templates, validation or carefully controlled automation.
Reducing catalogue and content effort can lower TCO while improving time to market and customer experience.
It may also remove the apparent need for a new platform. Many “platform limitations” are actually ownership and workflow problems.
9. Redesign the support and agency model
Retailers sometimes pay several partners to manage different parts of the same commerce ecosystem.
One agency may support the platform, another the frontend, another integrations, another analytics and another campaign delivery.
Specialisation can be valuable. Fragmented accountability is expensive.
It can create:
- Duplicate investigation
- Partner handoffs
- Unclear incident ownership
- Repeated discovery
- Conflicting recommendations
- Longer release cycles
- Knowledge gaps
- Excessive coordination
- Commercial incentives that reward effort rather than outcomes
Review the support model against:
- Scope clarity
- Response performance
- Resolution performance
- Repeat incidents
- Cost by work type
- Knowledge retention
- Release throughput
- Preventative improvement
- Commercial outcomes
Support expenditure should be divided into:
- Planned enhancement
- Preventative maintenance
- Routine operation
- Incident response
- Repeated failure
A high support budget is not automatically problematic. A high proportion spent resolving the same underlying issues is.
Agency commercials should also encourage simplification. If a partner’s revenue increases whenever the environment becomes harder to operate, the incentives are misaligned.
A stronger model rewards measurable improvements in stability, delivery efficiency and commercial performance.
10. Remove low-value operational complexity
Retail organisations frequently carry requirements that were introduced for valid historical reasons but no longer justify their cost.
Examples include:
- Rare promotion combinations
- Legacy customer groups
- Obsolete payment methods
- Duplicate fulfilment rules
- Market-specific exceptions
- Old account workflows
- Unused reports
- Bespoke approval processes
- Parallel content models
- Product attributes no longer used
Each exception may affect code, testing, data and support.
Retailers should maintain a register of operational complexity and ask:
- How often is this capability used?
- Which customers depend on it?
- What revenue or margin does it support?
- What would happen if it were removed?
- How much does it add to ongoing change?
- Can the process be standardised?
Platform simplification cannot be separated from business simplification.
A retailer that migrates every historical exception onto a new platform will preserve much of its existing TCO.
Include commercial performance in the TCO model
Cost reduction should not weaken the commerce proposition.
A cheaper implementation that reduces conversion, availability or release speed may create a worse financial outcome.
TCO should therefore be assessed alongside:
- Revenue
- Gross margin
- Conversion
- Average order contribution
- Customer lifetime value
- Digital-influenced store sales
- Release throughput
- Availability
- Performance
- Operational risk
A useful financial model is:
Platform and operating cost + transition cost + cost of failure − incremental commercial contribution
This prevents the retailer from selecting the lowest-cost technology model while ignoring the value it must support.
Platform vendors increasingly include conversion and revenue effects within their TCO arguments. Shopify, for example, defines TCO across platform fees, implementation, operations, support and conversion impact. Its published conclusions naturally favour Shopify, so retailers should validate assumptions against their own business model.
The same scrutiny should be applied to every vendor comparison.
When replatforming is justified
Optimisation-first does not mean remaining on the existing platform indefinitely.
Replatforming may be justified when:
- The platform no longer supports the business model.
- Required capabilities involve repeated workarounds.
- The product is approaching end of support.
- Security or compliance risks cannot be managed acceptably.
- Operating skills are becoming unavailable.
- Change remains expensive after implementation debt is addressed.
- The platform prevents important customer or operational capabilities.
- The three-to-five-year economics remain unfavourable after optimisation.
- The organisation is prepared to simplify rather than migrate every legacy requirement.
The business case should compare at least three options:
| Option | Appropriate when |
|---|---|
| Optimise | The platform remains suitable but the implementation or operating model is inefficient |
| Upgrade and simplify | The platform is suitable, but version and customisation debt are increasing cost |
| Replatform | There is a fundamental mismatch between the platform and the future business model |
A fourth option may involve replacing selected components while retaining the core platform.
For example, a retailer may modernise search, content, frontend delivery or order management without replacing the entire commerce engine.
Account for the transition cost properly
A replatforming model should include:
- Discovery and architecture
- New implementation
- Data migration
- Data cleansing
- Integration redevelopment
- Capability replication
- Search-engine transition
- Analytics rebuilding
- Content migration
- Quality assurance
- Security review
- Staff training
- Change management
- Parallel operation
- Contract overlap
- Launch support
- Post-launch optimisation
- Initiatives deferred during migration
- Risk allowance
These costs should be compared with recurring savings across an appropriate period.
An apparent reduction in annual platform cost may take years to recover once transition costs are included.
The model should also account for capabilities that will be simplified or removed. If the new platform appears cheaper because the comparison excludes functionality the existing business relies on, the two options are not equivalent.
Avoid platform-led business cases
The decision should begin with the retailer’s economics and operating model—not with a preferred technology.
Adobe Commerce may remain the right platform for a retailer that relies on complex catalogues, account structures, pricing or custom workflows.
Shopify Plus may offer a better model for a retailer whose requirements align closely with the platform’s standard capabilities and who values reduced infrastructure responsibility.
Salesforce Commerce Cloud, BigCommerce and composable approaches each create different cost, control and capability profiles.
The question is not which platform has the lowest average TCO.
It is:
Which operating model produces the best financial outcome for this retailer’s actual requirements, scale, capabilities and growth strategy?
That assessment may support replatforming. It may support remaining on Adobe. It may support simplifying Adobe first and reviewing the decision again with better evidence.
A credible adviser should be comfortable with all three conclusions.
What a strong TCO program delivers
Reducing ecommerce TCO should produce more than a smaller technology budget.
The program should aim to create:
- Lower recurring operating cost
- Faster and less expensive releases
- Fewer incidents
- Reduced manual administration
- Better platform stability
- Simpler architecture
- Clearer ownership
- Improved customer experience
- Greater investment capacity
- A more credible replatforming decision
The strongest outcome may be that the existing platform can operate more efficiently.
Alternatively, the analysis may demonstrate that replatforming is economically justified. In that case, the retailer enters the program with a clearer understanding of its requirements, costs and unnecessary complexity.
Either result is better than choosing a new platform based on licence comparisons and vendor claims.
Reduce complexity before replacing capability
Ecommerce TCO is rarely created by one decision.
It accumulates through customisations, integrations, applications, manual processes, deferred maintenance and delivery practices. Replatforming can remove some of that cost, but it can also carry the complexity forward under a new commercial model.
Retailers should first determine:
- What must remain
- What creates competitive value
- What can be standardised
- What should be retired
- What is genuinely caused by the platform
Only then can they compare platforms fairly.
The role of an ecommerce agency should not be to use cost pressure as a reason to recommend its preferred technology.
It should help the retailer build a defensible financial model, simplify the current environment and determine which combination of platform, architecture and operating model produces the strongest long-term result.
Sometimes that means replatforming.
Sometimes it means making the platform already in place substantially less expensive to own.
