Choosing an e-commerce platform: control, costs and daily work

What we would do

We build PrestaShop modules, so read our recommendation with that interest in view. For an existing store, we would first test the missing requirement on the current setup. A slow category, awkward theme or failed connector needs a diagnosis before it becomes a reason to replace the platform.

The route depends on your installed modules and custom code, integrations, theme, data quality, selling markets and the people who maintain the shop. Record which requirement the present store cannot meet and what fixing it would cost. Compare that with a replacement that has proved the same workflow using your data, including the work of retraining staff and rebuilding integrations.

When a change is justified, prepare a clean, supported target and test it away from production. For changes within PrestaShop, use a staging copy with the actual theme, modules and configuration; for a platform move, rehearse imports into the proposed target. Isolate test payments, emails and fulfilment exports, protect copied customer data and keep the test shop out of search results. Rehearse the final data sync and planned switch, with a return plan that accounts for orders taken after launch.

For an uncertain PrestaShop requirement, the PrestaShop Module Selection & Fit Assessment tests native settings, module candidates and the need for custom development on a controlled shop copy.

Which route should you test first?

Choose the operating model

Start with who will run the store. Shopify supplies a hosted commerce service. With self-hosted PrestaShop, you choose the host and control the application files and database. For self-hosted PrestaShop, you can delegate infrastructure maintenance to a managed host. An agency can maintain store customisations and integrations on either platform.

Managed hosting can reduce your technical workload. It does not remove your responsibility to agree who applies patches, restores backups and handles incidents. A hosted platform also leaves you responsible for staff accounts, app permissions, product rules, tax setup and customer data handling.

If you need a simple launch with little infrastructure work, a hosted service deserves a trial. If you need direct data access or application changes, test a self-hosted option. Catalogue size or monthly revenue alone cannot decide this choice.

Understand licences and portability

PrestaShop core uses the Open Software License 3.0. Themes, modules and bundled dependencies have separate licences. Source access gives you control over a licensed copy; it does not transfer the copyright to you.

Your store includes more than its database. Configuration spans database tables and files such as app/config/parameters.php. The table prefix is configurable; ps_ is only an example. Keep application files, modules, overrides, themes, images, uploads, downloads and cryptographic secrets in your recovery plan, together with the database. Record PHP, database and web-server settings. Test a complete restore.

Separate moving hosts from changing platforms. A hosting move can preserve the PrestaShop application after configuration changes. Replatforming still requires field mapping and replacement of incompatible themes, modules and integrations.

• Test exports of products, combinations, images, customers, orders, discounts and SEO fields before committing.
• Map historical orders, subscriptions and app-specific records separately.
• Plan password resets where password hashes cannot be transferred or reused.
• Ask your payment provider about saved-card token portability. Database ownership does not make processor tokens portable.
• Compare URL requirements before choosing: Shopify uses fixed /products/ and /collections/ prefixes, while PrestaShop lets you configure friendly-URL patterns under Shop Parameters > Traffic & SEO. Check canonical tags, hreflang and structured data in the proposed implementation. Build a URL redirect map and validate important landing pages.

A self-contained module can remain usable after its author stops trading, within its licence. External services, activation checks and future runtime changes can still affect it. Obtain terms for updates, support and service dependencies before buying. For commissioned work, agree source delivery, licence rights, build instructions and access to service accounts before development starts. Have the shop hold the credentials needed for another maintainer to take over.

Use the backup guide and platform migration guide when planning an exit.

Compare costs on equivalent assumptions

Build a three-year budget using the same merchant country, settlement currency, tax basis, card mix, payment methods, transaction count and billing term. Include international cards, currency conversion, refunds, disputes and any negotiated rates. Convert foreign-currency quotes consistently.

36-month total = setup + theme + migration
               + hosting or platform subscriptions
               + apps/modules and update/support renewals
               + development, maintenance and staff time
               + payment processing and applicable platform transaction fees
               + backups, monitoring, tax services and other integrations
Payment processing = sum(volume for each payment type × its rate)
                   + sum(transaction count for each payment type × its fixed fee)

Shopify subscription fees, payment-processing fees, third-party-provider transaction fees and app charges are separate items. Additional transaction fees depend on the plan and payment arrangement, with exemptions including eligible Shopify Payments arrangements. PrestaShop core does not add a percentage platform fee to sales. Your processor, modules and external services can still charge transaction fees.

The following sales scenarios are planning inputs, not recommended platform thresholds. They show only arithmetic for a constant monthly volume. A one percentage point rate difference is hypothetical and excludes fixed per-payment fees.

For each scenario, enter actual transaction counts and equivalent processor quotes on both sides. Do not compare a US card rate with an EEA card rate. Apply platform fees only to eligible transactions. Then add the other budget lines before drawing a conclusion.

Check Shopify pricing and its transaction-fee rules for your country. Record the quote date and billing term. Promotions are not the long-term renewal price.

Compare extension baskets feature by feature. A purchased module licence and access to future updates are different rights. PrestaShop Marketplace Business Care includes an initial subscription and annual automatic renewal unless cancelled. Independent vendors and WooCommerce extension suppliers set their own terms. Include those renewals and external-service subscriptions.

Calculate migration payback only after obtaining a migration quote and estimating your own recurring savings. Include cutover work and the cost of operating both stores during transition. In the EUR 25,000 monthly example, the hypothetical percentage-point difference produces EUR 9,000 over 36 months only if that volume and rate difference apply throughout. It is a budget line to set against implementation, renewals and maintenance, not a saving you can assume from choosing PrestaShop.

Turn the budget into a supplier worksheet

Give each supplier the same requirement list. Against every item, record whether it is native, a paid extension, an external service or custom work; name the edition, licence holder, renewal basis and person responsible for updates. Ask what changes if you add a market, replace the theme or stop paying for support. An unpriced integration is an unresolved budget item.

Evaluate Shopify capabilities and limits

Shopify combines hosting, storefront administration, payment integrations and an app ecosystem. This can reduce the number of infrastructure suppliers you coordinate. Launch still depends on product preparation, payment approval, shipping, taxes and required integrations.

Checkout and custom development

Shopify supports custom apps, APIs, Functions and checkout extensions within its platform rules. Checkout branding and supported public Functions apps are available below Plus. Supported post-purchase and thank-you/order-status extensions are also available on lower plans. UI extensions on the information, shipping and payment pages require Plus. Custom Functions apps have separate plan restrictions. Match each required change to the checkout app availability table.

On PrestaShop, you can extend checkout through modules, hooks and development. That flexibility requires compatibility and payment-flow testing. For a replacement checkout, use the Checkout Revolution help page.

Payments, tax and network services

Shopify Payments, Shop Pay, Capital, Balance, Installments, Audiences, POS and Inbox address different payment, financing, marketing and retail tasks. Check each service's country, plan, hardware and eligibility requirements. Financing approval is separate from opening a store.

Shop Pay has native integration benefits, but eligible external commerce platforms can integrate it through the Shop Pay Wallet API. It is not exclusive to a Shopify storefront.

Shopify Tax includes EU and UK VAT features, as well as services for other supported markets. Verify the invoicing and tax workflow you need. Neither a tax engine nor a payment module completes all your reporting obligations.

Support and app selection

The pricing comparison lists 24/7 live chat on standard plans and priority phone support for Plus. Check the current support entitlement before contracting. For any platform, test supplier response and define an incident contact route.

App-store review is a useful selection input. Still assess permissions, compatibility, data transfers, support and exit terms for each app. Test a real retail sale and refund if POS is part of your business. For example, sell an item online and return it in the shop using the proposed POS workflow. Check where staff find the order, which system issues the refund and how stock changes. A shared product list alone does not prove that the retail and online operations fit together.

Evaluate PrestaShop operations and maintenance

You can manage products, orders and customers through the back office without writing PHP. Technical work remains necessary for hosting, faults, integrations and upgrades. Plan who will provide it.

• Use native languages, currencies, tax rules, customer groups, specific prices, cart rules, combinations and packs where they meet your requirements.
• Currency precision is distinct from the configured price-rounding mode and rounding type. Test invoices and refunds in every selling currency.
• Choose payment-provider modules and check country/currency restrictions. Configure tax rules, invoicing, consent and reporting for your jurisdictions.
• Test multistore sharing and module behaviour in each shop context. Decide whether customers, stock and other settings should be shared before rollout.

PrestaShop combines legacy classes and controllers with Symfony-based administration. Hooks allow extensions without editing core, but they do not guarantee compatibility with future PHP, platform or theme releases. Prefer documented extension points and retest each module during upgrades.

Use Update Assistant, whose technical module name is autoupgrade, for a supported upgrade path. Clone into an isolated staging environment, verify module/theme compatibility, run the upgrade and test the complete purchase and refund flow before production.

Match PHP to the exact PrestaShop release, modules and theme. PrestaShop 9.0 supports PHP 8.1 to 8.4; later 9.x releases have their own compatibility matrix. Choose a supported PHP branch permitted by that matrix. See the version-specific system requirements.

PrestaShop includes Smarty and CSS/JavaScript cache settings. The 9.0 installation configuration enables Smarty caching and CSS/JS smart caches. Review actual settings after installation or migration. OPcache depends on hosting. Redis integration, reverse-proxy caching and CDN services require additional configuration. A Redis monitoring module does not create an application cache. Follow the cache guide when testing personalised prices, carts and sessions.

Use staged testing, measured response times and restore tests to assess readiness. Source availability, a brand name or raw CVE counts do not tell you which platform is safer or faster for your store.

Compare PrestaShop with WooCommerce

WooCommerce adds commerce to WordPress. It is a practical candidate when your existing workflows depend on WordPress publishing, its block editor, taxonomies, scheduling and media tools. PrestaShop provides CMS pages; a publishing workflow may need an additional module. Blog Revolution adds multilingual articles, publication scheduling and links between advice and catalogue products. Trial the editorial work your staff actually do before treating that as a replacement for an established WordPress publishing process.

Do not treat all WooCommerce data as post metadata. Product data uses the WordPress model together with commerce lookup tables. High Performance Order Storage stores orders in dedicated tables when enabled. Check extension compatibility with HPOS.

Compare native functionality with the extension basket you would actually install. PrestaShop includes multilingual catalogue fields, currencies, customer-group pricing, combinations and multistore. For WooCommerce, specify how languages, currency switching, B2B pricing and multi-site operation will work. Both offer product variants, promotions and tax configuration; advanced validation and automation can require extensions on either side.

Test a content editing task, variant purchase, customer-group price and refund in both candidates. Measure search, filtering and checkout with equivalent data, traffic and cache states. Include WordPress, WooCommerce, theme and plugin updates in the maintenance plan. Avoid choosing from a universal product-count cutoff or an assumed performance ranking.

Compare Magento Open Source and Adobe Commerce

Separate Magento Open Source from paid Adobe Commerce and its B2B extension. Quotes, requisition lists and purchase-order approvals in Adobe Commerce B2B are not all included in the free Magento edition.

Magento development uses Composer, dependency injection, service contracts, XML layout and plugins/interceptors. Deployment can involve bin/magento setup:upgrade, dependency-injection compilation and index management. Include this workflow in your agency and hosting quotes. Store staff still carry out daily catalogue and order work in its administration interface.

Use the dependency matrix for the exact release to select a supported search engine and cache/session services. Built-in full-page caching is available. Adobe strongly recommends Varnish for production; this recommendation is separate from the catalogue-search requirement. Redis, Valkey and search-engine support vary by release.

Demonstrate your actual multi-website, attribute, ERP and B2B workflows before paying for them. For example, have a trade buyer request a quote, a manager approve the purchase and staff send the resulting order to the ERP. Record what happens when the buyer changes the basket after approval. A demonstration of customer-group pricing alone does not establish that the quotation and approval process works. Compare equivalent implementation quotes and load tests. Neither a RAM figure nor a threshold such as 50,000 SKUs establishes when you must switch platforms.

Compare PrestaShop with Shopware

Shopware 6 provides Store and Admin APIs, a data abstraction layer and a standard server-rendered Twig storefront. Its administration uses JavaScript components. Evaluate it when you need multiple sales channels or a custom storefront.

Server rendering and APIs can coexist. PrestaShop 9 includes an Admin API for administration and integrations; that does not make it a complete storefront API. For a headless project, demonstrate catalogue and price retrieval, customer sign-in, cart, checkout and payments, then map the integration requirements and any extra endpoints or custom development they need.

Shopware supports extension ZIP upload, installation, activation and updates through Extensions > My Extensions. Composer and CLI deployment are additional workflows. Ask your implementer which workflow your deployment uses.

Compare Shopware Sales Channels with PrestaShop multistore using your domains, assortments, languages, currencies, stock and customer-sharing requirements. Trial the actual configuration in each system. Get hosting quotes for the same load and required services. Search-engine needs depend on the release and workload.

Compare self-managed and hosted commercial offers separately. Check edition features, licence/service terms, local support and extension documentation in the languages your team uses. Ask your own staff to follow the supplier's instructions for a routine product change and your developer to explain the release process. This tests whether the local support and skills you can actually buy fit the deployment, rather than assuming a platform's home market decides suitability.

Compare PrestaShop with OpenCart

Trial both administration interfaces with your catalogue and staff. OpenCart includes options, attributes, special prices, quantity discounts, customer groups, tax rates, tax classes and geo zones. These are not all extension-only capabilities.

Compare the precise stock model you need. In PrestaShop, a combination can have its own reference and quantity. In OpenCart, inspect how option values, identifiers and quantity changes behave in your selected release. Test a complete size-and-colour matrix, packs and supplier updates instead of treating all variants as equivalent. For a clothing store, import a supplier reference and stock quantity for each size-and-colour pairing, buy a pairing and refund it. Check that only the intended stock changes and the supplier update still identifies the same item. Selectable size and colour fields are not enough evidence of the stock model you need.

Both platforms support multiple stores. OpenCart allows product and category assignments to selected stores. Test the exact sharing boundaries for customers, orders, prices, stock, themes and language settings rather than assuming that distinct assortments require PrestaShop.

OpenCart provides an event system as well as version-dependent modification mechanisms such as OCMOD. Modification-based extensions and event subscribers have different integration risks. PrestaShop hooks also require compatibility testing. Compare the specific extensions you need and their supported releases.

Check friendly-URL generation and bulk editing on your chosen release. Benchmark equivalent catalogues and extension stacks. Review dated release histories and maintained dependencies; avoid assuming that either project is declining or that one query count predicts performance.

Run a practical selection trial

1. Write down essential workflows: publishing, languages, currencies, taxes, combinations, stock, B2B, POS, shipping, returns and integrations.
2. Separate requirements available in the selected edition from paid extensions and custom development.
3. Use a representative sample catalogue, including difficult variants and pricing rules.
4. Ask the staff who will use the store to add a product, process an order and refund it.
5. Test exports, backups, restores and a realistic integration failure.
6. Compare the same three-year cost categories, support commitments and release-testing workload.
7. Choose the option that meets your requirements with a maintenance arrangement you can sustain.

Keep a requirements sheet with pass or fail evidence

For every essential workflow, save the test input, expected result, actual result and person responsible for any gap. Keep the proposed release, theme, extensions and configuration with the result so the supplier cannot substitute a different demo later.

PrestaShop remains a candidate when you want application access and can arrange maintenance. Shopify, WooCommerce, Magento Open Source, Adobe Commerce, Shopware and OpenCart address different operating needs. Your trial, contract terms and implementation plan should decide the fit.

Spot comparison traps before you sign

Plan the switch and the handover

A successful trial proves the proposed setup can do the work; it does not move the live business. If your existing store takes orders while the replacement is being built, decide how changes made during that period reach the target. Use the platform migration guide for the detailed move.

1. Agree the data scope: catalogue, customer accounts, orders, discounts, content, redirects and integration-specific records. Record what is imported, retained for reference or rebuilt, and who signs off each result.
2. Rehearse on a protected staging target with the intended releases and extensions. Reconcile records and business totals with the source, then have staff carry out the purchase, fulfilment and refund checks.
3. Time the actual procedure and plan the trading interruption from that rehearsal. Decide when catalogue edits, stock feeds and new orders stop, and how pending payments and shipments will be reconciled.
4. Take recoverable copies before the final sync. Import changes since the rehearsal, reconcile the final data and switch storefront traffic and integrations in the agreed order. Give each export, scheduled task and payment notification a named owner so the old and new shops do not both send live work.
5. Validate the public domain, redirects, indexability, analytics, emails, checkout and downstream orders. Remove staging-only restrictions from the intended live target while keeping the old and test copies protected from public indexing.
6. Use agreed stop conditions if payments, order handling or data checks fail. Keep the old environment available for the return plan, and reconcile any orders, payments or stock movements created after the switch before returning traffic. Restoring an earlier database alone can lose new business records.

What to ask your developer or agency

• Which requirements fail on the present shop, and what evidence rules out a smaller repair?
• Which release, edition, theme, modules and service contracts are included in the quote, and where are the acceptance results?
• Who owns the hosting, domain, licence and integration accounts, and can another maintainer obtain the source and deployment instructions?
• How will you reconcile the final import, pending transactions and changes made while both environments exist?
• What triggers a return to the old shop, and how will you preserve activity after the switch?
• Who handles incidents, extension updates, restore tests and staff training after handover?

Questions owners ask

Who decides whether the trial passed?

Name a business owner for each essential workflow. Have the staff who will operate it sign off the recorded results, and have your developer explain any technical limitations. The supplier should demonstrate the solution; your business decides whether the result meets the agreed requirement.

Should we choose a platform now for a business we hope to become?

Test the next confirmed requirement and price the route to it. A speculative headless storefront or approval system needs an owner, a business case and a maintenance budget before it belongs in the essential requirements.

Can we keep the old store open after launch?

Keep a protected reference copy if you need historical access, with an agreed retention and access policy. Designate the live system for taking payments and sending fulfilment work. Leaving both shops' jobs and connectors active can produce conflicting orders or stock.

What if our preferred agency supports only one candidate?

Ask it to prove your requirements and price the dependencies it proposes. For an essential workflow outside its experience, obtain an assessment from someone who maintains that candidate. Familiarity is useful evidence about available support, but it is not proof that the platform fits.

What should happen to requirements that fail the trial?

Agree a demonstrated fix, a priced scope change or a different candidate before committing. Record an optional feature as optional only when the business owner accepts the consequence. Do not leave an essential payment, stock or tax workflow as an unexplained promise for after launch.