Time to read: 9 minutes
Content
A lower platform license fee does not necessarily make a lower-cost commerce operation. Integration work, data reconciliation, training, overlapping contracts and the exposure of switching systems can change the comparison.
The reverse is also true: a familiar platform is not automatically cheaper if it requires persistent manual work or cannot support an essential store flow. Compare keeping, repairing, modernizing a component and replatforming against the same required operation, scope and time horizon. Include the price of transition, not only the price of the destination.
Repair when the cause is localized and the current platform can carry the requirement. Modernize one component when a single part is the constraint. Replatform when material requirements remain unsupported after checking bounded remedies, or verified operating economics justify the move after transition costs. Keep and support when flows work, support is viable and limitations are acceptable.
The ecommerce lead should define the sales capability that matters; operations defines continuity; IT tests feasibility and ownership; finance compares future obligations. The sponsor's decision is which viable scenario to fund—not which proposal has the lowest headline fee.
These are working definitions, not vendor product categories. A proposal can combine them, but it must say what changes and what stays.
“Unknown” is not another word for “custom required.” Check the installed edition, supported configuration, current connector and incumbent's scope first. Equally, a feature on a comparison chart is not proof it works with your ERP, loyalty rules and store procedure. Retaining a usable connector or customer-data service is a legitimate outcome.
Agree storefronts, markets, locations, order mix, catalog/customer scope, peak demand, launch window and planning horizon before comparing totals. A hypothetical 36-month view can be useful; finance should choose a horizon that exposes the relevant renewals, support and transition obligations.
Start the clock on the same decision date, not at each option's eventual go-live. Otherwise a longer implementation disappears from the comparison. Record when each option begins satisfying the requirement, and include costs while the old operation is still running. Use the same demand assumptions; keep speculative revenue gains separate from cost.
Assess each option against the same operating requirements:
For every requirement and option, record demonstrated fit, gap with an estimated remedy, accepted limitation or unknown, plus version/date, evidence, owner and recurring obligation. A small repair may not affect a requirement, but establish that through impact review. Never average a non-negotiable return requirement into a feature score.
Illustrative estimate structure, not prices or a client result. A merchant repeatedly corrects refunds by hand. Before asking for four proposals, establish whether the cause is a disabled supported setting, an incorrect mapping or a capability gap.
Keeping the workflow prices its accepted manual effort and support. Repair prices a configuration/mapping correction and regression checks. Component modernization prices the replacement, interfaces, data access and coexistence. Replatforming adds history access, migration, reconciliation, training and cutover to the new workflow's recurring costs.
A verified setting correction is a counterexample to “refund problems require migration.” Conversely, a low repair quote is not good value if it leaves a required rule unmet. Give every estimator the same outcome and evidence; otherwise the totals price different problems.
Total cost of ownership should explain its boundary, not merely display a total. Use one ledger per option and the same comparison header: decision date, horizon, currency/tax basis, volume and peak assumptions, included systems, service scope, delivery dates, quote validity and finance's treatment of inflation or discounting, if used.
| Cost line | Include | Timing or evidence to record |
|---|---|---|
| Licenses and subscriptions | Platform, required apps/connectors, tiers and minimums | Setup, recurring fees, renewal terms and billing driver |
| Infrastructure and tooling | Hosting, search, monitoring, environments and storage | Setup/usage; distinguish bundled charges |
| Support and maintenance | Upgrades, security maintenance, integration ownership | Recurring coverage and exclusions |
| Manual operations | Reconciliation, rekeying, exceptions, campaign workarounds | Observed volume × time × agreed loaded rate |
| Implementation | Repair/configuration, component or platform work, testing, coordination | Defined packages, dependencies and exclusions |
| Data and reconciliation | Mapping, cleanup, trial/final changes and historical access | Vendor effort plus internal owners; residual work |
| Training and handover | Store/CMS procedures, practice and materials | Initial effort and recurring refresh if required |
| Overlap and validation | Dual licenses/environments, coexistence and support | Expected duration plus extension case |
| Cutover, stabilization and exit | Rehearsal, coverage, export, decommissioning, termination | Contract evidence and timing; count each charge once |
Each line needs amount/range, quantity/unit, period, cash versus internal effort, source/date, estimator and fact/estimate/unknown status. A current invoice proves a stated billing period; future usage is still an estimate unless established contractually. Missing amounts are unknown, not zero.
A simple undiscounted planning view is: future one-off costs (including exit costs due within the horizon) + recurring costs over the common horizon. Disclose exit fees falling just beyond that horizon rather than exploiting the cutoff. This is a budgeting structure, not a validated investment algorithm.
Fictional worked calculation—not market prices or client evidence. Use a decision date of January 1, 2027 and the same January–December 2027 horizon for both options: 12 months. All amounts are invented EUR cash, excluding VAT, with flat charges, no discounting and no revenue benefit credited. Assume both end states meet the requirement and interim legacy operation is acceptable. Recurring bundles cover licenses, hosting, apps and external support; migration's one-off work includes prelaunch staging. No other cash charges are assumed for this illustration.
Counterexample: omitting transition reverses the apparent cheaper option. Work plus target-platform running cost alone makes migration look like €12,000 + €6,000 = €18,000, or €10,000 below repair's €28,000. Restoring the omitted €12,000 legacy run + €2,000 overlap + €1,000 exit adds €15,000: migration is €33,000, so repair has €5,000 lower modeled cash cost instead. Keep internal staff hours in a separate capacity record, not as cash savings. Unknown interruption/recovery exposure remains unpriced—not zero.
Count each future obligation once. An unknown amount is not zero.
Avoid three misleading forms of savings. Do not charge the same work twice: separate vendor migration-testing fees from additional internal reconciliation effort and count each platform's overlap cost once. Do not confuse released capacity with cash reduction: saved staff hours may free capacity without reducing payroll; do not count the same benefit again as incident savings. Do not let sunk costs decide: past implementation spend is not a future outflow, but remaining contractual obligations may be.
Keep the requirements, cost fields and recommendation for each option in one small decision record. It needs no default prices, risk probabilities or winner.
Keep-and-support retains incident exposure; repair can regress; a component change adds interfaces and coexistence risk; replatforming adds data and cutover obligations. None supplies a downtime probability.
For each material scenario, record the affected operation, likelihood evidence if available, assumed duration, business impact, prevention/recovery work and accepting owner. An unsupported probability multiplied by hourly revenue produces precise-looking fiction. Finance should separate delayed demand from lost sales, and revenue from contribution. Keep unquantified exposure beside TCO rather than silently adding a guessed risk cost.
A phased launch can limit the first wave but extend dual operation. Specify which system owns each event and how the wave differs from remaining stores or channels. Software rollback does not undo a refund, pickup or fulfillment already completed; budget business-record reconciliation as well as technical restoration.
Budget URL mapping, canonical/redirect checks, analytics and forms, representative peak-flow tests and CMS handover where affected. Keep campaign interruption and uncertain organic-search effects visible; “no SEO loss” is not a guaranteed benefit.
Dinarys's public Prostor case describes Magento 2 migration, pickup, custom loyalty and ERP/CRM integrations. It reports that platform patching and a headless-only approach were rejected because the constraints involved the backend and omnichannel operation, not presentation alone. It also describes early inventory-sync reconciliation followed by frequency changes and a validation layer.
Those are relevant components and decision context for comparing a smaller change with a migration. They are not your TCO benchmark, a guarantee of continuity or proof your current platform should be replaced. Include reconciliation ownership and stabilization effort in your comparison rather than assuming integration is finished at launch.
Summarize operating fit, future-cost range, timing, retained components, transition exposure, unresolved assumptions, owner and evidence that would change the recommendation. A supported configuration, a load test locating the constraint outside the core, or a rehearsal exposing inaccessible legacy orders can change the shortlist. A narrow check may resolve the decisive uncertainty.
If migration remains justified, use Dinarys's ecommerce migration and replatforming service to discuss scoped implementation and transition ownership. If the evidence favors a repair or retaining the platform, keep that conclusion visible.
Want to compare the viable paths? Discuss your fit-gap/TCO record with Dinarys. Bring the required operation, current invoices and contracts with sensitive details removed, incident/manual-work observations, key integrations and open assumptions. Include operations, IT and the budget approver. Choose the evidence first, not the largest project.
Our certified specialists will find the most optimal solution for your business.
