Re-platform or Optimise: A Framework for the Right Decision
Commerce platform decisions are made by committees, driven by frustration, and validated by vendor proposals. Here is how to make one properly.
Why This Decision Is Usually Made Wrong
The re-platform decision is rarely made from a position of clear analysis. It is usually made under pressure — from a platform incident, from a board-level conversation about digital competitiveness, from a competitor’s launch, or from accumulated frustration with a system that has been stretched beyond its original design. Under those conditions, the decision gets made before the problem is properly defined.
The result is a pattern the industry has seen repeatedly: an 18-month re-platform project that reproduces the functional limitations of the old platform in a new codebase, at significant cost, while the original problems — which were often organisational and operational rather than technical — remain largely unchanged after go-live.
The framework below is not about which platform to choose. It is about defining the problem clearly enough to know whether changing the platform is actually the solution.
The Optimization Ceiling Test
Before evaluating re-platforming, you need an honest assessment of what your current platform can and cannot do. Most platforms are not operating at their ceiling. Most implementations are running on default configurations, with accumulated technical debt, under-optimized integrations, and without the architectural improvements that have been available on the platform for years.
The optimization ceiling test asks: have you actually reached the limit of what this platform can do, or have you reached the limit of what your current implementation can do?
Indicators that you have not hit the platform ceiling:
- Core Web Vitals are below threshold but no performance optimization work has been done in the last 24 months
- Checkout conversion is below benchmark but no systematic A/B testing program has been run
- The platform has released major features in the last two years that your implementation has not adopted
- Integration latency issues exist but no integration audit has been conducted
- Development velocity is low but the release process and codebase architecture have not been examined
- Customizations are heavily duplicated across the codebase with no shared component structure
Indicators that you are approaching the platform ceiling:
- You are running on a version the vendor no longer supports and upgrade paths are genuinely blocked by incompatible customizations
- Business requirements exist that the platform architecture structurally cannot support — not “it would be difficult” but “it is not possible without a workaround that creates more problems than it solves”
- Licensing costs have scaled to a point where the total cost of ownership comparison with a migration is material over a three-year horizon
- The integration model requires data transformations or API behaviors the platform cannot perform at the volume your business requires
The distinction matters because optimization projects typically run 3 to 6 months and preserve business continuity. Re-platform projects typically run 12 to 18 months and introduce substantial risk throughout.
The Feature Parity Trap
The single most common cause of re-platform project overruns is what practitioners in the implementation community call feature parity: the requirement that the new platform reproduces every behavior of the current platform before go-live.
Feature parity sounds reasonable. In practice, it is how 12-month projects become 24-month projects.
Every commerce platform accumulates behavior over years of operation — promotional logic, edge cases in the checkout flow, customer account behaviors, integration quirks that have become load-bearing dependencies. Most of this behavior is undocumented. It surfaces during QA, when testers compare the new platform against the old one and raise defects for every behavioral difference. If every difference is treated as a defect, the project does not end until all of them are resolved.
The alternative is to define minimum viable parity: the specific behaviors that must be preserved because they are commercially significant or legally required, and to explicitly accept behavioral changes in everything else. This requires stakeholder alignment that most organisations find politically difficult to achieve before the project starts. It is also the difference between a project that ships and one that does not.
For Salesforce Commerce Cloud implementations specifically, minimum viable parity scope typically includes: promotion engine logic, tax calculation behavior, shipping method resolution, payment flows, and customer account data integrity. Everything related to storefront presentation — content layouts, navigation structure, filtering behavior — should be treated as a redesign opportunity rather than a migration target.
The Real Cost of Re-platforming
Re-platform projects are systematically undercosted at the approval stage. The full cost includes categories that are rarely present in vendor proposals or initial business cases.
Platform licensing. The new platform license, projected at your anticipated GMV for the next three years — not your current GMV. For Salesforce Commerce Cloud, the revenue-share or GMV-based fee structure means the license cost scales with the business success the migration is intended to enable.
Implementation. The development cost of the migration project, including QA, project management, and technical architecture. Most business cases underweight QA and project management by 30 to 40 percent. A realistic allocation is 30 percent of total development effort for QA and 15 percent for project management.
Integration rebuild. Every integration to your current platform — ERP, OMS, WMS, PIM, marketing automation, loyalty, review platforms — needs to be rebuilt or re-mapped. Each one takes longer than estimated. The ERP integration alone typically represents 15 to 25 percent of the total project cost and is the most common source of go-live delays.
Content migration. Product copy, marketing content, page layouts, and media assets all need to migrate. The volume is always larger than the initial estimate. The data quality issues discovered during migration always require remediation work that was not in scope.
Team capability gap. If your team does not have direct experience on the new platform, plan for a 6-to-12-month productivity gap post-go-live while they develop platform fluency. This is a real cost that does not appear in implementation proposals.
SEO continuity risk. URL structure changes, page behavior changes, and site speed regressions post-go-live all affect organic search performance. The revenue impact of a 20 percent organic traffic reduction during the 6 months it takes to recover from a poorly managed migration frequently exceeds the total cost of the migration project itself.
Risk contingency. Budget a contingency of at least 25 percent of the total project cost. Re-platform projects have a measurable failure and overrun rate, and the contingency is not pessimism — it is accurate planning.
SEO Continuity as a First-Class Decision Variable
SEO continuity is routinely underweighted in platform migration decisions and overweighted in post-launch retrospectives. It deserves to be a first-class variable in the decision analysis, not a checklist item assigned to the marketing team in the final month of the project.
A well-managed migration to Salesforce Commerce Cloud can preserve and improve organic search performance. A poorly managed one produces a traffic regression that takes 6 to 18 months to recover from, with a direct revenue impact that belongs in the business case.
The SEO continuity workstreams required in any significant platform migration include:
URL inventory and redirect mapping. Every URL that currently receives organic traffic needs a 1:1 redirect mapping. In practice, legacy URL structures — Magento’s category/product URL patterns, SAP Commerce’s URL encoding conventions — do not map cleanly to SFCC’s native URL structure. This is a significant data project that should start during discovery, not implementation.
Structured data continuity. If the current platform has schema markup — Product, BreadcrumbList, FAQPage, Organization — the new implementation needs equivalent coverage from day one. Schema regressions are technically invisible to users but have measurable impact on rich result eligibility and CTR.
Core Web Vitals at launch. It is common for a new platform implementation to launch with worse performance scores than the site it replaced. Prioritizing performance configuration before launch — not as a post-launch optimization task — is the difference between a smooth organic transition and a 3-month traffic regression while Google re-evaluates the page experience signals.
Canonical URL configuration. SFCC’s native URL handling has specific behaviors around faceted navigation, sorting parameters, and pagination. Incorrect canonical tag configuration or missing exclusions for parameter-based URLs creates duplicate content issues that affect organic performance in the months following launch.
A Decision Framework
Re-platform when:
The platform has a structural technical ceiling that blocks a specific commercial outcome, and that outcome has clear revenue attribution that exceeds the fully loaded cost and risk of migration over a three-year horizon.
The platform vendor has signalled end-of-life for your current version and the upgrade path is genuinely blocked — not merely difficult — by incompatible customizations or dependencies.
The total cost of ownership on the current platform, including licensing, platform-specific talent, technical debt maintenance, and the opportunity cost of features you cannot build, exceeds the TCO of migration over three years.
The business is entering a phase where the commerce platform needs to scale significantly, and the current architecture cannot support that scale without infrastructure investment that approaches the cost of migration.
Optimise when:
The platform has capabilities your implementation has not adopted. Migrating to a new platform to access features the current platform already supports is not a business case for migration.
The primary complaints are about development velocity and code quality. These are implementation problems, not platform problems, and they will travel with you to the new platform if not addressed structurally.
The business cannot absorb 12 to 18 months of reduced engineering velocity while a migration consumes the majority of development capacity.
Core Web Vitals and storefront performance are below benchmark. Most commerce platforms — including Magento 2, Shopify Plus, and SFCC on SFRA — can be optimized to meet performance thresholds without re-platforming. Migration is not a performance strategy.
Neither yet — prepare first when:
The business case for migration exists in principle, but the integration landscape is not mapped, the URL inventory is not complete, and the feature requirements are not documented with acceptance criteria. Starting a re-platform without these three things in place is the primary driver of scope growth and overrun. A focused 6-to-8-week discovery engagement before committing to migration is not delay — it is the difference between a project that finishes and one that does not.
Migrating to Salesforce Commerce Cloud Specifically
For brands migrating to SFCC from Magento 2, SAP Commerce, or Shopify Plus, several platform-specific considerations influence both the decision and the approach.
Customer passwords cannot be migrated. Password hashing algorithms differ between platforms. There is no technically sound approach to migrating hashed passwords. The migration approach — forced password reset on first post-migration login via a secure reset flow, or a parallel authentication pathway during a defined transition period — needs to be made as a business decision and communicated to customers before go-live, not discovered during QA.
Order history migrates as read-only data. Historical orders can be stored in SFCC as reference records, but the SFCC order data model differs from most legacy platforms in structure and field mapping. The transformation is significant and should be scoped explicitly. Brands that assume order history migrates cleanly consistently discover this late.
Catalog complexity dominates early workstreams. SFCC’s product catalog structure — master products, product variants, product sets, product bundles — maps differently from Magento’s simple/configurable/grouped/bundle model, from SAP’s product hierarchy, and from Shopify’s product/variant model. Catalog migration is typically the first workstream to start and the one that surfaces the most data quality issues in the source system.
The promotion engine requires explicit mapping. SFCC’s promotion engine is powerful but has a specific rule structure and operator logic. Legacy promotion configurations — particularly conditional stacking rules, tiered discounts, and B2B pricing arrangements — require explicit translation rather than direct migration. This is frequently underestimated in scoping and surfaces during integration testing.
The Conclusion
The re-platform or optimise question is not answered by which platform is more technically capable. It is answered by a clear definition of the commercial problem, an honest assessment of whether the current platform can solve it with the right implementation work, and a rigorous understanding of what migration actually costs and risks.
For most businesses facing commerce platform frustration, the right first step is an optimization audit rather than a vendor evaluation. Not because re-platforming is never the answer, but because the decision should be made with accurate information about both options — and that information is rarely available at the point when the decision is typically made.
Coredevex provides with a structured migration methodology built around SEO continuity, integration sequencing, and minimum viable parity definition. If you are evaluating this decision and want a practitioner’s assessment of your specific situation,