Which to choose: PrestaShop or OpenCart for a self-hosted store
Choose PrestaShop when your store will depend on system-to-system integration, several storefronts, or a long-term plan to extend the core through its own code. PrestaShop Core is licensed under OSL-3.0 and its modules under AFL-3.0, and both the 8.x and 9.x lines still receive releases, with 9.2.0 published on September 30, 2026. PrestaShop 9 also adds an Admin API built on API Platform with OAuth2 authentication, multi-shop support and Swagger documentation, which matters if an ERP, warehouse or marketplace connector needs to read and write products, orders and customers. If that integration work is central to the project, confirm the Admin API endpoints your connectors need against the PrestaShop 9 developer documentation before you commit.
Choose OpenCart when you want a lightweight cart, a large extension catalog and a simpler upgrade path. OpenCart is licensed under GPLv3, its 3.0.x and 4.x lines were both released on August 11, 2026, and its README describes patch versions as safe to apply. The marketplace lists more than 13,000 modules and themes, and opencart.com offers OpenCart Cloud as a hosted alternative to self-hosting. The trade-off is that the README closes bug reports about third-party modules and directs you to the extension developer, so the stability of your store depends heavily on the add-ons you pick. Check the maintenance status and PHP compatibility of each extension you need before you choose.
The decision turns on four things: how deep your integrations go, how many third-party extensions the store must run, whether your team has in-house PHP skills to maintain a custom build, and whether you will apply patch and feature releases on a fixed schedule. A merchant with one storefront, a handful of proven extensions and a small team often fits OpenCart. A merchant with multiple shops, a heavy integration layer and a developer who will own the codebase often fits PrestaShop. If you are unsure, ask a partner to scope a short proof of concept against your own catalog and integrations, and request a written quote that covers hosting, upgrades and extension maintenance.
Which platform fits which merchant scenario
This table maps common merchant situations to the platform that usually fits better and the condition that decides it. Read each row against your own catalog, integrations and staffing, because the better fit often changes when one condition flips.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Single shop with a payment gateway and no integrations | OpenCart | Standard gateway and shipping modules exist in the marketplace, and the shop does not need an API for outside systems. Confirm the gateway extension is maintained for the version you run. |
| Multi-shop group under one team | PrestaShop | Multi-shop support is a core need, and the group wants shared catalog and settings across storefronts. Confirm the shop groups you need against the PrestaShop 9 documentation before committing. |
| Store feeding an ERP or PIM through an API | PrestaShop | PrestaShop 9's Admin API uses OAuth2 and Swagger documentation, which suits system-to-system work. Confirm that the endpoints your ERP or PIM needs are covered, since a legacy webservice may also be in play. |
| Merchant reliant on marketplace extensions | OpenCart | The team plans to buy most features as ready-made extensions and wants the largest catalog of modules. Vet each extension's maintainer, since OpenCart's README directs module bug reports to the developer, not the core project. |
| Team with no PHP staff | Neither as a self-run install; consider a hosted option | Without in-house PHP skills, both platforms need a partner or hosted service for upgrades and patching. OpenCart Cloud is a hosted option to compare against self-hosting costs. |
| Team that expects frequent core upgrades | PrestaShop (on the 9.x line) | The team wants to stay on a maintained major line. PrestaShop 9.2.0 and the 8.x line both received releases in 2026, so confirm which line your upgrade plan targets. |
| Shop with strict license and reuse requirements | PrestaShop | Core is OSL-3.0 and modules are AFL-3.0, which suits teams that want a permissive, file-level copyleft model. OpenCart is GPLv3, which requires derivative distributions to share source under the same terms. |
How PrestaShop and OpenCart are built and deployed
Both carts are PHP applications that run on a conventional LAMP-style stack, so the hosting decision looks similar on paper. The differences sit in database and web server requirements, the PHP version you must keep current, and how each project tells you to install and update it. Read these cards before sizing a server or writing a patch calendar.
PHP version and patch cadence
PrestaShop 9 is the platform you plan around for a long run, and its own requirements page lists MySQL 5.7 or MariaDB 10.2 as the minimum database. OpenCart's README sets a minimum of PHP 8.0, and its Docker development environment defaults to PHP 8.4 with MariaDB. Confirm which PHP minor version each release you pick supports before you commit, because a PHP upgrade can force a cart upgrade and a retest of every installed extension.
Database floor and version drift
PrestaShop 9 sets MySQL 5.7 or MariaDB 10.2 as its minimum, which are older database versions than many current managed services still offer. Plan the database version alongside the PHP version rather than treating it as a fixed host setting. Ask your hosting provider which MySQL or MariaDB versions it supports, and whether it will upgrade them on your schedule or its own.
Web server and Unix hosting
PrestaShop 9 runs on Apache 2.4 or later, and Nginx also works. The documentation says it works best on Unix-based systems and that Windows is not actively supported. If your team runs Windows servers, this is a hosting decision you must make before the project starts, not a configuration detail. OpenCart's supplied requirements do not make the same statement, so confirm its Windows support directly with the project.
Production installs from releases
The PrestaShop README says its GitHub repository is for development and preview, and that production shops should be installed from the releases page. A team that clones the development branch to production gets an unsupported build. Build your deployment pipeline to fetch tagged release archives, verify them, and keep a record of which build each environment runs.
Docker for development, not a default
OpenCart's Docker development environment defaults to PHP 8.4 with MariaDB, which gives a fast local test bed that matches a known stack. That environment is not a production recommendation. Ask your team to test the same extension set against the same PHP and database versions as production, and to confirm with the project whether its container images are supported for production use.
Operations and extension load
Both carts run as a single PHP application with a database, so day-to-day operations look similar: cron jobs, file permissions, cache directories and backups of both files and database. Extensions multiply this work. Each added module may need its own PHP or database support, and OpenCart's README directs module bug reports to the extension developer. Keep a written inventory of every module and who supports it.
How the Admin API changes integration work in PrestaShop 9
PrestaShop gives integration teams two documented routes into the shop, and the Admin API in PrestaShop 9 is the one to evaluate first for new work. The older webservice gives third-party tools CRUD access to shop resources such as products, orders and customers, authenticated with access keys. PrestaShop 9 adds an Admin API built on API Platform, authenticated with OAuth2, with multi-shop support and Swagger documentation. For a merchant planning an ERP, marketplace or fulfillment connection, that means a standard, browsable contract and token-based authentication instead of only per-key access. Before you commit, confirm in the PrestaShop 9 developer documentation which endpoints cover your product, order and customer objects, and whether they handle the writes your process needs.
OpenCart reaches the same kind of integration through its extension model rather than a comparable core API. Connectors for payment gateways, shipping, accounting or marketplaces typically arrive as third-party modules, so the quality, update cadence and security posture of each integration depend on the module developer. The OpenCart README closes bug reports about third-party modules and directs users to the extension developer, the forum or a commercial partner. That means a broken connector after an upgrade is a support question you route yourself. Your team should inventory every module the integration needs, check its last release against the OpenCart version you run, and record who owns its fixes.
Confirm three things before you design around either model. First, whether the Admin API's OAuth2 setup, client registration and scopes match how your identity team issues service credentials. Second, how multi-shop configuration changes the data your integration reads and writes. Third, whether your chosen connector is maintained for your target version, since on OpenCart that check is an extension question and on PrestaShop 9 it is a question about your own integration code. Testing these in a staging copy of the shop, with a realistic order volume, will show the effort more reliably than any comparison table.
Capabilities and facts compared head to head
This table sets PrestaShop and OpenCart side by side on license, maintained version lines, requirements, API surface, extensions and hosting. Read each row as a checkpoint: where the supplied facts are firm, they are stated, and where a detail changes your decision, the cell tells you what to confirm before you commit.
| Capability | PrestaShop | OpenCart |
|---|---|---|
| Core license | Core under OSL-3.0 (LICENSE.md in the PrestaShop repository) | GNU General Public License version 3 (LICENSE.md in the OpenCart repository) |
| Module and extension license | Modules under AFL-3.0; confirm terms for each third-party module you plan to use | Set by each extension author; confirm license terms per extension before purchase or install |
| Latest maintained releases | 9.2.0 (September 30, 2026); 9.1.5 and 8.2.8 (August 18, 2026), so both 9.x and 8.x are receiving releases | 4.1.0.4 and 3.0.5.1 (both August 11, 2026), so both 4.x and 3.0.x are receiving releases |
| Minimum PHP | Confirm the PHP version for your target PrestaShop line in the 9 system requirements before provisioning | Minimum PHP 8.0 per the README; the Docker development environment defaults to PHP 8.4 with MariaDB |
| Minimum database | MySQL 5.7 or MariaDB 10.2 minimum for PrestaShop 9; Apache 2.4 or later, with Nginx also working | Confirm the supported database and versions for your OpenCart line in its installation documentation |
| API surface | Webservice gives CRUD access to products, orders and customers via access keys; PrestaShop 9 adds an Admin API on API Platform with OAuth2, multi-shop support and Swagger docs | Confirm the API and its scope for your version in the OpenCart documentation before relying on it for integrations |
| Extension ecosystem | Modules and themes ecosystem; confirm the maintenance status of each module against your PrestaShop line | Marketplace listed by opencart.com as more than 13,000 modules and themes; quality and maintenance vary, so review each one |
| Payment and shipping extensions | Payment services supported through modules; confirm the specific gateway and carrier modules you need | Feature releases add extensions such as payment gateways and shipping modules; bug reports on third-party modules go to their developers |
| Official hosted option | Confirm with PrestaShop whether an official hosted offering exists for your region and needs | OpenCart Cloud, a fully hosted version with multiple plans, offered by opencart.com as an alternative to self-hosting |
What the OSL-3.0, AFL-3.0 and GPLv3 licenses mean for a shop
PrestaShop Core is licensed under the Open Software License 3.0 (OSL-3.0), and PrestaShop modules fall under the Academic Free License 3.0 (AFL-3.0). OpenCart is licensed under the GNU General Public License version 3 (GPLv3). These are different license texts with different conditions, so the license name alone does not tell you what your shop may do with its code. Neither fact decides modification or redistribution obligations on its own, because those depend on what you change, what you combine and whether you distribute copies outside your organization.
- Core and modules differ: A PrestaShop shop typically combines OSL-3.0 core code with third-party modules that may carry AFL-3.0 or other terms. Map each component to its license before procurement signs off.
- Copyleft scope: GPLv3 has copyleft terms that can reach derivative works. Ask counsel how those terms apply to custom themes and modules you write for OpenCart.
- Hosted services: Confirm how each license treats software you run as a service for customers, since distribution and network use are handled differently across these texts.
- Paid support: Ask each vendor whether support, upgrades or editions are sold separately. The supplied facts describe OpenCart Cloud as a hosted option with multiple plans, but they do not describe paid editions for either platform.
- Legal review: Obtain written advice from qualified counsel on your specific structure before relying on any interpretation.
Check the license file in each repository and the terms of every third-party extension you plan to install.
For developers, the practical question is which code you modify, which code you only call, and how each extension is packaged. Core changes, theme overrides and extension code can sit under different terms, so keep them in separate repositories and track their license headers. Confirm the terms of each module or extension before you copy its code into your project.
- Core modifications: Changes to PrestaShop Core fall under OSL-3.0 terms. Keep a record of every core patch and prefer overrides or module hooks where the platform supports them.
- Module boundaries: Keep custom modules in their own packages with their own license file, so their terms are visible during audits.
- OpenCart extensions: The OpenCart marketplace lists more than 13,000 modules and themes, which carry varied licenses. Check each one before installing it.
- Header hygiene: Scan the codebase for license headers and third-party notices during each upgrade so that copied snippets do not carry unexpected terms.
- Upgrade effort: Patched core files can complicate moving to a new maintained release, so license tracking and upgrade planning should happen together.
Before your next release, run a license scan of the full shop codebase, including themes and modules, and send the results to counsel.
What drives the running cost of each cart
This table lists the main cost components for running PrestaShop or OpenCart yourself, showing who is paid, what is one-time versus recurring, and what to request in a quote. The license is only one line, so read the rows together: most of the running cost comes from hosting, extensions, integrations, testing and upgrade work. OpenCart's free download carries zero monthly fees according to opencart.com, but that does not make the total cost zero.
| Cost driver | PrestaShop | OpenCart |
|---|---|---|
| License | OSL-3.0 core and AFL-3.0 modules. No license fee for the core, but confirm module licenses for each paid add-on. | GPLv3 core. Zero monthly fees for the free download per opencart.com. Extensions carry their own terms. |
| Infrastructure (one-time setup, recurring hosting) | Recurring hosting for Apache or Nginx, MySQL or MariaDB, and PHP with memory_limit of at least 512M. Ask the host for sizing under your catalog and traffic. | Recurring hosting for PHP 8.0 or later with MariaDB, as the Docker setup defaults to PHP 8.4. Ask for sizing under your catalog and traffic. |
| PHP and database operations | Recurring patching of PHP, MySQL 5.7 or MariaDB 10.2 minimum, and the web server. Confirm the supported database versions for your target release line. | Recurring patching of PHP and MariaDB. Patch releases are described as safe to apply, but schedule and test them on staging each time. |
| Extension purchases and maintenance | Modules are a mix of free and paid. Recurring module license renewals and compatibility checks after each core update. | Marketplace lists more than 13,000 modules and themes per opencart.com. Paid extensions recur through vendor terms, and bug reports about third-party modules go to the developer, so budget for vendor support. |
| Integration development (payments, shipping, ERP) | One-time build of payment, shipping and back-office connectors. Recurring cost to keep them current, using the webservice or Admin API as the integration point. | One-time build of connectors, often through extensions. Recurring cost when an extension lags a core release and needs replacing or custom code. |
| Security testing and hardening | One-time hardening and periodic testing of the storefront, admin area and API keys. Ask for test scope, retest terms and report format in writing. | One-time hardening and periodic testing, with extra review for each third-party extension installed. Ask for the same scope and retest terms. |
| Upgrade effort | Recurring testing of 8.x and 9.x lines. Confirm which line you target and how long each one stays supported before planning moves. | Recurring testing of the 3.0.x and 4.x lines, which are maintained side by side. Major moves between lines need a planned migration and extension recheck. |
| In-house versus outside skills | Recurring internal or retained time for PHP and PrestaShop administration. Hiring or contracting costs depend on local rates, so request a quote tied to your scope. | Recurring internal or retained time for PHP and OpenCart administration. Smaller ecosystem of specialist developers in some regions, so confirm availability before committing. |
Moving a live store from OpenCart to PrestaShop, or back
This sequence turns a live store move into a checked, reversible project, so the catalog, orders, customers and integrations arrive intact and the merchant can roll back if the cutover fails. It works in either direction because the same inventory, export and test steps apply to both platforms.
Inventory extensions, integrations and their replacements
List every installed OpenCart extension, theme customization, payment gateway, shipping module, ERP or accounting connector, and marketing tool. For each one, record what it does, whether PrestaShop or the destination offers a native or module-based equivalent, and who owns the replacement decision. Confirm with the extension developer or the destination platform's marketplace which items have no equivalent. The output is a signed-off replacement register, with items marked as native, third-party module, custom build or dropped. Because OpenCart's README directs extension bug reports to the developer, record each developer's support contact now.
Export catalog and customer data
Export products, categories, attributes, options, images, product-level SEO fields, customer accounts and address books from the source store, using a database export or a supported import tool that you verify against the destination's import format. Map OpenCart fields to PrestaShop equivalents, noting that multi-language and multi-currency fields and customer password hashes may need specific handling. Confirm with the destination platform how customer passwords are migrated, whether they can be imported as hashes, and whether customers must reset them. The output is a field-mapping document and a row-count reconciliation that matches source and exported records.
Migrate order history and financial records
Export historical orders with line items, totals, tax lines, statuses, refunds and payment references, and load them into the destination as read-only records where the platform allows it. Keep the source store reachable in read-only form for accounting and returns queries. Confirm with your accountant which tax and invoice numbering rules must be preserved and whether the destination can store historical order numbers. The output is a reconciled order ledger that totals to the source for a sample period agreed with finance.
Map URLs and set up redirects
Build a table of every indexed OpenCart product, category and content URL, along with the PrestaShop URL that replaces it. Configure permanent redirects for each mapped pair and review the list for pages with no destination, so they can be handled deliberately instead of returning errors. Test a sample of high-traffic and high-backlink URLs in staging. The output is a redirect map loaded into the destination, with a crawl report showing no unexpected 404 responses on mapped paths.
Reconfigure payments, shipping and taxes
Rebuild payment gateways, shipping carriers, rate tables, tax rules and currency settings on the destination, using the gateway vendor's current credentials and sandbox accounts. Do not copy production API keys between platforms without a security review. Test each payment method end to end, including authorization, capture, refund and webhook handling, and each shipping rate against sample addresses. Confirm with each provider whether their module supports the destination's current version. The output is a test log showing a successful transaction, refund and label or rate result for every enabled method.
Rebuild integrations against the PrestaShop API
For each custom or third-party integration identified in the inventory, rebuild the connection using PrestaShop's webservice or Admin API rather than porting OpenCart code. The webservice gives CRUD access to products, orders and customers with access keys, and PrestaShop 9 adds an Admin API with OAuth2 and Swagger documentation. Confirm with your developers which endpoints and permissions each integration needs, and store credentials in a secrets manager. The output is an integration test suite that runs against staging and covers create, update and read paths for each data object.
Test in staging and run a parallel order check
Run the migrated store on a staging copy that mirrors production hosting, PHP settings and database engine. Execute scripted test orders covering guest checkout, registered checkout, discounts, returns, refunds and stock changes, and confirm that integrations receive the expected events. Compare the staging store's catalog, prices and customer counts against the reconciled exports. The output is a signed test report with every failed case either fixed or accepted in writing by the business owner.
Cut over with a documented rollback plan
Freeze catalog and pricing changes on the source store, run a final incremental export of orders and customers, apply the redirect map and DNS or routing change, and then verify live transactions in the destination. Keep the source store and its database available in read-only mode for an agreed period, and define in advance the specific failure conditions that trigger rollback, such as payment failures or missing orders. Confirm the rollback steps with your hosting provider and the destination platform's support channel before the change window. The output is a cutover log and a rollback runbook that the on-call team has rehearsed.
Where PrestaShop and OpenCart implementation projects run long
Most overruns in PrestaShop and OpenCart projects come from the extension layer, not the core install. Before work starts, list every module or extension the shop depends on and confirm it has a version that runs on the target release. On PrestaShop, check module compatibility against the 9.x line you plan to run, since PrestaShop 9 added an Admin API and other changes that older modules may not account for. On OpenCart, the 4.x and 3.0.x lines are both receiving releases, so decide which line you are on before you buy extensions, because an extension built for one line does not carry over to the other. Ask each extension vendor in writing which versions they support and how long they will keep supporting them.
Runtime alignment and payment certification are the next two sources of delay. PrestaShop 9 requires MySQL 5.7 or MariaDB 10.2 minimum, Apache 2.4 or later or Nginx, and a memory_limit of at least 512M, and the developer documentation says Windows is not actively supported. OpenCart's README shows a minimum PHP version of 8.0. Confirm the PHP and database versions on your hosting stack early, because a host that is one version behind can block the install. Payment gateway certification is also slow to schedule and depends on the acquirer or gateway, not on the cart, so start that request in parallel and ask the payment provider what test environment and sign-off it requires.
Theme rebuilds, order and customer migration, and integrations usually take the largest share of the schedule. A custom theme often has to be rebuilt against the new template structure, and the rebuild grows with every custom page and checkout step. Migrating orders and customers means mapping identifiers, addresses, tax rules and order statuses, then reconciling totals and sample orders before cutover. Integrations with ERP, accounting or fulfillment systems can use PrestaShop's webservice with access keys, or OpenCart's extension hooks, and each one needs its own test cycle. Timelines depend on the written scope, so ask for each of these items to be listed as a separate deliverable with its own acceptance check.
Questions merchants ask before hiring help with PrestaShop or OpenCart
What drives the cost of a PrestaShop or OpenCart project?
Cost depends mostly on the work in the written scope, because both platforms are open source and the software itself carries no license fee. OpenCart's site describes zero monthly fees and free downloads and updates, and PrestaShop Core is licensed under OSL-3.0. Costs fall into two groups. One-time costs include discovery, theme and design work, module selection, custom development, data migration, payment and shipping integrations, testing and go-live. Recurring costs include hosting, PHP and database upgrades, module updates, backups, security patching and support. Costs rise with custom features, catalog size, the number of integrations and the number of third-party extensions that need configuration. Ask every provider for a quote that separates one-time and recurring items and names who performs each task.
How long does a PrestaShop or OpenCart migration or build take?
The supplied information does not give a duration for a migration or build, so do not treat any timeline as a benchmark. Duration follows from scope. A theme-based launch on a fresh install takes less time than a migration from another cart that carries custom pricing rules, several payment gateways and ERP synchronization. Ask for milestones tied to the written scope, the order in which tasks depend on each other, and which steps wait on your decisions, such as product data cleanup or tax rules. DeployOpen works on fixed-scope engagements where scope, deliverables and timelines are agreed in writing before work starts, so request the timeline as part of that document.
What does our team need to provide during a platform project?
A project moves at the speed of the merchant's inputs, so confirm four things before work starts. Access means administrator accounts for the shop, hosting, DNS, the payment and shipping providers, and any existing store or database. Data means product catalogs, customer and order records, tax tables and images, along with a named owner who can approve the export. Decisions cover theme direction, which modules to keep, how checkout and returns should work, and who approves changes to pricing. Sign-off means a named approver for each milestone, a test plan both sides accept and a go-live window. Delays usually come from slow decisions and missing data, not from the code.
Can an in-house team run PrestaShop or OpenCart without outside help?
An in-house team can run either platform if it has PHP and Linux operations skills and time for regular upgrades. The supplied requirements set the baseline. PrestaShop 9 needs MySQL 5.7 or MariaDB 10.2 at minimum, Apache 2.4 or later (Nginx also works), and a memory_limit of at least 512M, and its documentation says it works best on Unix-based systems. OpenCart's README shows a minimum PHP version of 8.0. Ongoing work includes applying patch releases, testing feature releases, checking module compatibility, backups and security response. OpenCart's README says bug reports about third-party modules are closed and redirected to the developer, the forum or a commercial partner, so your team will own module troubleshooting. Retainers for ongoing support, upgrades and continuous testing are available if that workload exceeds your capacity.
Which PrestaShop or OpenCart version line should we choose?
Choose PrestaShop 9 for new builds that need the Admin API, which the PrestaShop 9 developer documentation describes as built on API Platform with OAuth2 authentication and Swagger documentation. PrestaShop 9.2.0 was published on September 30, 2026, and 8.2.8 on August 18, 2026, and the 8.x line still receives releases. Stay on 8.x only if a required module or theme is not yet confirmed for 9, and confirm that with each module vendor in writing. On OpenCart, 4.1.0.4 and 3.0.5.1 were both published on August 11, 2026. OpenCart's README treats patch versions as safe to apply, while feature releases add extensions such as payment gateways and shipping modules. Check which line each required extension supports before you commit.
Does a hosted option remove the need for operations work?
A hosted option removes some server work but leaves configuration, content, module choices and payment settings with you. OpenCart offers OpenCart Cloud, a fully hosted version with multiple plans, as an alternative to downloading and self-hosting. The supplied information does not list the plan limits, module support, data export terms or who handles upgrades, so request those terms in writing before you decide. Self-hosting keeps control of infrastructure and data location in your hands, which can matter for merchants with regulatory or contractual data residency requirements. Compare the two options on total responsibility, not on the monthly price.
Do OSL-3.0 and GPLv3 limit what we can change or build on?
Both are open-source licenses that allow modification, but their conditions for distributing modified code differ. PrestaShop Core is licensed under OSL-3.0, and PrestaShop modules are under AFL-3.0, according to the PrestaShop repository's license file. OpenCart is licensed under the GNU General Public License version 3. Private customizations that stay inside your own business usually raise different questions than a modified build you distribute to others. Have legal counsel confirm what applies to your custom code, to any purchased modules and to any agency deliverables, and check the license of each third-party module separately before installing it.
How DeployOpen helps choose, implement or migrate between these carts
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For PrestaShop vs OpenCart, we start by confirming which cart fits your catalog, integrations and hosting constraints, then work from a written scope.
How we scope
- Written scope covers which cart, edition and version line you target, and why it fits your catalog and integrations.
- We record required payment, shipping, ERP and identity integrations, and which ones depend on extensions or modules.
- Hosting target is agreed up front: your cloud account, data center or air-gapped network, with PHP and database versions checked.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- Installation follows the vendor requirements for the chosen line, including PHP, database and web server versions.
- Customizations and integrations are built against the platform's own extension model or Admin API, with the licensing of each module reviewed.
- Testing covers checkout, payments, orders and data flows in a staging environment before any production change.
- Security hardening and configuration are documented against your own policies and the platform's security guidance.
How we hand over
- Handover includes architecture notes, configuration records, extension inventory and the upgrade procedure for your chosen line.
- For migrations, we document data mapping, cutover steps and rollback steps so your team can verify each stage.
- Backup and restore procedures are documented and tested as part of the delivery, not left as a later task.
- Runbooks name who owns each task after go-live, so your team knows what to patch, monitor and test.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering minor and patch releases on your line.
- Before a major version change, we plan the upgrade scope in writing, including extension compatibility checks.
- Support questions about third-party modules are routed to the extension developer or vendor, as the platform documentation advises, and we help you assess them.
- Ask your quote to name retainer scope, response expectations and what happens when a version line reaches end of support.
