Magento Open Source vs PrestaShop: when each platform fits
Magento Open Source fits a store with a large or complex catalog, and a team that can operate its service stack. Magento Open Source 2.4.9 requires PHP 8.5, MariaDB or MySQL 8.4, OpenSearch 3, RabbitMQ 4.3 and Valkey 9, and Adobe supports only the listed combinations. That is a reasonable footprint for an in-house team or a partner that already runs search, queues and caching as production services. It also fits a merchant willing to plan upgrades around Adobe's patch cadence, where 2.4.9 has standard support until May 31, 2029.
PrestaShop fits a simpler stack, a PHP hosting environment the team already runs, and a smaller operations footprint. PrestaShop 9 requires 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. For a catalog that is moderate in size and a store run by a small internal team, that lighter set of dependencies usually means fewer services to patch, monitor and back up. Confirm the expected catalog size, peak order load and hosting target against these minimums before you assume it fits.
Licensing will not separate these two platforms. Both cores are OSL-3.0, so the decision turns on catalog and order volume, the number of back-office and payment integrations, who will run the platform, and how much upgrade work the business can absorb each year. Ask each vendor or partner to map your integrations to the PrestaShop 9 webservice or Admin API and to Magento's extension APIs, then estimate the maintenance load for your own module list. An illustrative test: if the store must expose a large product feed to several marketplaces, the search and queue services in Magento will carry real operational weight.
Which platform fits which store scenario
This table compares Magento Open Source and PrestaShop across common store scenarios and names the better fit in each case, along with the condition that makes it so. Read each row as a starting point, then test your own catalog, order volumes and integrations in a load test before deciding, because neither platform's suitability should be judged from a generic threshold.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Large catalog with complex attributes and promotions | Magento Open Source | Choose it when catalog depth, indexing needs and custom pricing rules are the main load, and when you can staff the heavier service stack. Confirm performance with a load test on your own data. |
| Smaller or simpler catalog with a fast path to launch | PrestaShop | Fits when the catalog is contained, the store needs standard merchandising and payments, and a lighter operational footprint matters more than deep customization. |
| Multi-shop or multi-language operation | Magento Open Source | Favored when many storefronts share one back end with heavy localization and store-view logic. Confirm that the specific multi-shop setup you need is supported in the edition and release line you choose. |
| B2B-style ordering with negotiated pricing and approvals | Magento Open Source | Stronger when you need customer groups, custom catalogs and complex quoting. Native B2B depth is largely an Adobe Commerce feature, so confirm which functions you would need to build or license separately. |
| Team with no Linux operations skills | PrestaShop | Easier to run on a conventional PHP and MySQL host with a simpler service set. Without Linux skills in-house, plan for managed hosting or a retained operations partner either way. |
| Existing PHP team with Symfony or Composer experience | Magento Open Source | Suits teams already comfortable with Composer-managed PHP, dependency upgrades and queue and search services. Teams that know PHP but not these services should budget time to learn them. |
| Heavy third-party integration through APIs | PrestaShop | PrestaShop 9 documents a webservice with access keys and an Admin API using OAuth2. Confirm that your ERP, OMS or PIM connectors support those interfaces, or plan custom integration work. |
| Integration with GraphQL-based storefronts or headless front ends | Magento Open Source | Magento Open Source exposes GraphQL, which many headless builds use. Confirm the exact queries and mutations your front end needs against the release line you pick. |
| Store that must stay on a stable release line for several years | Magento Open Source | Adobe lists standard support for 2.4.9 until May 31, 2029, and says it ships a full patch for the 2.4.x LTS line each May. Check the current support table before committing, and plan a supported-line upgrade path. |
How Magento Open Source and PrestaShop are built and hosted
Both platforms are PHP ecommerce applications that you run in your own infrastructure, but the amount of supporting software differs sharply. Magento Open Source depends on a service stack of search, queue, cache and proxy components that each need patching and monitoring. PrestaShop 9 has a lighter requirement list, with more of the work sitting in the application itself.
Magento's service stack
Magento Open Source 2.4.9 requires PHP 8.5, MariaDB or MySQL 8.4, OpenSearch 3, RabbitMQ 4.3, Valkey 9 and nginx 1.30 on Linux x86-64, and Adobe supports only the listed combinations. Each service is a separate version you must track, patch and monitor, so the platform team needs to own the whole stack rather than just the shop code. Check every component version against the requirements before scheduling a patch window.
Varnish as full-page cache
For self-managed installations, Adobe documents Varnish as the full-page cache accelerator, which sits in front of the application and must be configured to match the store's caching rules. Cloud-hosted Adobe Commerce uses Fastly instead, so a self-hosted team owns Varnish tuning, purge behavior and its own version upgrades. Ask who will test cache invalidation after each catalog or theme change, because stale pages are a common source of incidents.
PrestaShop 9 requirements
PrestaShop 9 requires MySQL 5.7 or MariaDB 10.2 at minimum, Apache 2.4 or later, with Nginx also working, and a memory_limit of at least 512M. The docs say it works best on Unix-based systems and Windows is not actively supported. The stack is smaller than Magento's, but the minimum database versions are older, so confirm the database version you plan to run is current and supported before you commit to it.
Releases page for production installs
The PrestaShop README states that the GitHub repository is for development and preview, and that production shops should be installed from the releases page. This matters for patching: your build pipeline should pin a tagged release and record its checksum, not track the default branch. Ask your team who reviews each release note, since the 8.x and 9.x lines both receive releases and need separate upgrade plans.
Docker development environment
The PrestaShop repository documents a Docker-based development environment for contributors and developers building themes or modules. It is a useful place to rehearse upgrades and test extensions before they reach the live shop, but it is not a production topology. Confirm whether your staging environment matches production in PHP version, database engine and cache setup, since a mismatch can hide problems that only appear under real load.
Side-by-side capabilities, licensing and release support
This table sets Magento Open Source and PrestaShop against each other on license, supported release lines, API model and caching, using only the versions and dates we can verify. Where a row depends on details we have not verified, such as module counts or identity provider connectors, the cell tells you what to confirm with each vendor before you decide.
| Capability | Magento Open Source | PrestaShop |
|---|---|---|
| Core license | OSL-3.0 for source files, with AFL 3.0 also included in the distribution | OSL-3.0 for PrestaShop Core, AFL-3.0 for modules |
| Latest release cited | 2.4.9, released May 2026; 2.4.10-alpha1 listed as released October 13, 2026 | 9.2.0, published September 30, 2026; 9.1.5 and 8.2.8 published August 18, 2026 |
| Support window | Standard support for 2.4.9 runs to May 31, 2029 under Adobe's lifecycle policy | Confirm the end-of-life date for each line with PrestaShop; the 8.x line is still receiving releases |
| Patch cadence | Full patch for the 2.4.x LTS line ships annually in May; security patches at least annually for supported lines | Confirm the security patch policy for 8.x and 9.x with PrestaShop before committing |
| Primary API model | GraphQL storefront and admin APIs; clearCart mutation is now available in Open Source | Webservice with access keys for CRUD on products, orders and customers; Admin API in PrestaShop 9 on API Platform |
| Admin API authentication | Confirm the token and OAuth options for your integration pattern in the Magento docs | OAuth2 in the PrestaShop 9 Admin API, with multi-shop support and Swagger documentation |
| Full-page caching (self-managed) | Varnish is the documented full-page cache accelerator for self-managed installs | Confirm the caching layer and reverse proxy setup for your hosting stack with PrestaShop |
| Identity provider or SSO connectors | Confirm available SSO modules and their license terms with Adobe or your extension vendor | Confirm available SSO modules and their license terms with PrestaShop or your module vendor |
| Module ecosystem size | Confirm the number of compatible extensions for your required functions in the Magento Marketplace | Confirm module availability for your payment, tax and logistics needs in the PrestaShop Addons marketplace |
Licensing, editions and what sits behind the paid tier
Magento Open Source is licensed under the Open Software License 3.0 (OSL-3.0), and the distribution also includes AFL 3.0 material. The source is published in the magento/magento2 repository. The free core delivers basic ecommerce capabilities without a license fee for the software itself, but it does not come with an Adobe support contract. Adobe sells Adobe Commerce as the commercial edition built on the same codebase, so features packaged on top of it belong to that edition.
- Core license: OSL-3.0 governs the source code, and no license fee is charged for the free distribution itself.
- Free core scope: basic store functions are included. Confirm each feature you need against the release notes for the exact version you deploy.
- Edition boundary shifts: the clearCart GraphQL mutation was Adobe Commerce only before 2.4.9 and is now available in Open Source, so a feature you assume is paid may move between releases.
- Support windows: Adobe's lifecycle policy lists standard support for 2.4.9 until May 31, 2029. Support from your integrator or hosting partner is a separate contract.
Check the license text and release notes for your target version, then confirm with Adobe which capabilities are Open Source for that release.
The paid features that merchants often ask about, such as content staging, returns management and the B2B extension, belong to Adobe Commerce, not to the free core. Adobe sells that edition with its own support and patch terms for licensed customers, and the license includes on-premises and Adobe-hosted cloud options. If your store needs any of these features, the decision moves to the sibling comparison Magento Open Source vs Adobe Commerce, which covers the feature list and licensed options in detail. This tab only sets the boundary.
- Commerce-only features: content staging, returns management and the B2B extension are the examples to test against your requirements.
- Licensed support and patches: Adobe's support and patch terms for licensed customers are separate from the release line lifecycle that applies to the free distribution.
- Hosting options: on-premises and Adobe-hosted cloud options come with the license, which changes who operates the infrastructure.
- Cost driver: license fees and terms are set by Adobe. DeployOpen does not set or estimate license pricing, so request the figure from Adobe.
- Edition drift: review each feature list against the release you plan to run, because capabilities can move between editions.
Ask Adobe for written license scope that maps to each feature you need before you design the store around it.
PrestaShop Core is licensed under OSL-3.0 and PrestaShop modules under AFL-3.0, according to the LICENSE.md file. The project says production shops should be installed from the releases page, and the development repository is for development and preview. The supplied release facts show 9.2.0 published on September 30, 2026, and 9.1.5 and 8.2.8 published on August 18, 2026, which means the 8.x line is still receiving releases alongside 9.x.
- Core and modules: OSL-3.0 covers the core and AFL-3.0 covers modules, so the terms of each module depend on its own license file.
- Free release line: the releases published on GitHub are the free distribution. Confirm the support end date for the line you choose with PrestaShop.
- Paid editions: no paid edition, paid add-on or support tier facts were supplied for this comparison, so ask the vendor whether any exist.
- Third-party modules: marketplace modules may carry their own license and support terms, which should be checked before purchase.
Ask PrestaShop to confirm in writing which paid add-ons and support tiers exist, what each covers and how long each release line is supported.
Your own modules inherit obligations from the license of the platform they extend. Magento Open Source and PrestaShop Core are both under OSL-3.0, and PrestaShop modules are under AFL-3.0, so the terms that apply to your code depend on how it is built, distributed and hosted. The questions to settle are whether you share the code outside your company, whether you copy code from licensed extensions, and whether the license requires you to publish source for work you modify. As an illustrative case, a merchant who commissions a module that runs only on its own servers faces different questions than a vendor who sells that module to other stores.
- Distribution: decide whether the module stays internal, is sold or is shared, because that changes what you must provide to each recipient.
- Modified core files: changes to core files raise different questions than a separate module that calls public interfaces. Confirm where the boundary sits with counsel.
- Third-party code: check the license of every library, snippet and Composer package your module includes.
- Upstream contributions: if you plan to contribute code back to the project, review its contribution terms first.
- License inventory: keep a record of the license for each dependency and release so an auditor or acquirer can trace what ships.
Have counsel review your module license plan before the build starts, and record the decision in the written scope.
What drives the running cost of each store
Running cost is mostly people and hosting, not the license, because both Magento Open Source and PrestaShop are OSL-3.0 cores with no license fee to pay. The recurring costs are the hosting stack, the people who patch and monitor it, extension and theme renewals, and any retainer with an agency or partner. Magento's stack is the heavier of the two. Adobe's 2.4.9 requirements list PHP 8.5, MariaDB or MySQL 8.4, OpenSearch 3, RabbitMQ 4.3, Valkey 9, Composer 2.10 and nginx 1.30, and for self-managed installs Adobe documents Varnish for full-page caching. Each of those is a service to host, secure, back up and upgrade. PrestaShop 9's documented minimums are MySQL 5.7 or MariaDB 10.2, Apache 2.4 or Nginx, and a memory_limit of at least 512M, so its baseline footprint is usually smaller. Confirm the sizing for your catalog and traffic with your hosting provider, because the minimums are not a production sizing.
Costs that land once are implementation, data migration, theme build and integration with your ERP, payment and shipping systems. Magento's extension count and themes usually mean more build and integration work, and PrestaShop's module marketplace may reduce custom code for common needs. Recurring costs include hosting, patch windows, module license renewals and support retainers. Magento's annual patch cadence and the lifecycle dates for 2.4.7, 2.4.8 and 2.4.9 mean a planned upgrade every year or so. For PrestaShop, plan around the maintained 8.x and 9.x lines, since 9.2.0 and 8.2.8 both shipped in 2026, and treat each major move as a project with testing and module compatibility checks. Ask your module vendors whether their paid add-ons have yearly renewals, per-store pricing or per-environment fees.
When requesting a written quote from an agency or implementation partner, ask for the upgrade path from your current release to the next supported line, the number of environments included (development, staging, performance test and production), and the test plan covering regression, payment and integration checks. Ask which hosting components are priced into the quote and which you provide, who patches the services and at what frequency, and who pays for module or theme renewals. Ask how a quote handles security patch windows and rollback. Ask for the fixed scope and deliverables in writing, so that recurring retainer hours are separated from one-time build work. Confirm all platform versions, support dates and module compatibility directly with Adobe, PrestaShop and each vendor before you sign.
Moving a store from one platform to the other
This sequence moves a store between Magento Open Source and PrestaShop with a known catalog, customer and order baseline, a tested staging copy, and a cutover that can be reversed. It is written for a team that has already chosen a direction and needs to plan the work in order.
Inventory the catalog, customers, orders and integrations
Start by listing everything the current store does: product count and attribute sets, customer accounts and groups, open and historical orders, tax and shipping rules, payment and shipping connectors, ERP or warehouse links, and any custom modules or themes. The store owner and the lead developer sign off on this list. It is done when every data set has an owner, a volume figure taken from the live database, and a yes or no on whether it must move.
Map data models and attributes between platforms
Compare how each platform stores products, categories, customer attributes and order records, then write a field-by-field mapping. Magento and PrestaShop model attributes, variants and multi-store scope differently, so each custom attribute needs a target field, a transformation rule, or a decision to drop it. Review the mapping with the merchandising and finance teams. It is done when every field in the inventory has a documented target or an approved exclusion.
Decide what is rebuilt and what is carried over
Product and customer data usually transfers with mapping and cleaning work. Themes, custom modules, checkout flows and payment or shipping connectors generally do not carry across, because they are written against each platform's own code and APIs. For each item, record whether it is rebuilt, replaced by an existing extension, or retired. Confirm the choice against the target platform's module ecosystem and its current API documentation. It is done when the rebuild list is agreed in writing with a named owner for each item.
Build the target store and migrate data into staging
Install the target platform on the hosting stack chosen for it, using the supported PHP, database and cache versions from the platform's requirements page. Load the mapped data into a staging environment that mirrors production as closely as practical, including search, cache and queue services. Document every import script and its run order so the load can be repeated. It is done when a full test import completes and record counts match the inventory within the tolerances the owner accepts.
Test checkout, integrations and security controls
Run end-to-end test orders through each payment method, tax calculation, shipping rule, email notification and ERP or warehouse connection. Repeat order and customer checks against the staging data. Review access control, admin accounts, API credentials and HTTP security headers on the new stack. Your security team or testing partner should record defects with severity and an owner. It is done when the agreed test cases pass or each open defect has an accepted workaround.
Run the cutover with a tested rollback path
Schedule a freeze window with the business, take a full backup of the source store and database, then run a final incremental data sync. Switch DNS or the load balancer to the new store only after the post-sync counts match. Keep the old stack running and its database intact until the team has confirmed that orders are flowing normally. Write down the exact rollback steps before the cutover and rehearse them in staging. It is done when the new store is live, the rollback has been rehearsed, and the on-call owner has signed off the first business day of orders.
Retire the old stack after a documented hold period
Once the hold period agreed in the plan ends, export a final archive of the old store for records, revoke its API keys and service accounts, and shut down its servers, search indexes and scheduled jobs. Remove DNS records and certificates that no longer serve traffic, and update the asset register and backup policy. Confirm retention obligations for order and customer records with your compliance lead before deletion. It is done when no production traffic reaches the old stack and the archive has been verified as readable.
What implementing each platform involves and where projects run long
Implementing Magento Open Source is mostly an infrastructure and tuning project, and the effort is front-loaded. The environment has to be provisioned for the full service stack that the Adobe Commerce system requirements for 2.4.9 list: PHP 8.5, MariaDB or MySQL 8.4, OpenSearch 3, Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30 on Linux x86-64, using only the combinations Adobe supports. Your team also has to choose full-page caching. Adobe documents Varnish for self-managed installations, so the Varnish configuration, indexing schedules and cache settings need to be tuned and load tested before go-live. Theme and extension selection comes next, and every extension is a dependency that must survive future upgrades. Security hardening includes Content Security Policy. From 2.4.7, CSP runs in restrict mode by default on storefront and admin payment pages, so confirm that payment providers and third-party scripts work under that policy before launch. Plan for the annual patch cycle as recurring work, not a one-time task.
A PrestaShop build concentrates effort in configuration, integration and multi-shop design. Server setup is lighter, since PrestaShop 9 requires MySQL 5.7 or MariaDB 10.2 minimum, Apache 2.4 or later (Nginx also works) and a memory_limit of at least 512M, and the docs say it works best on Unix-based systems. Module selection is the largest decision: each module is a long-term dependency, and its AFL-3.0 license and maintenance status should be checked individually. Theme work and payment configuration follow. For integrations, decide early whether the system will use the webservice with access keys, which gives CRUD access to products, orders and customers, or the PrestaShop 9 Admin API with OAuth2. If multiple shops share one catalog or back office, the multi-shop configuration must be designed before data is loaded, because changing it later is costly. Projects usually run long in four places. Integration testing takes more time than planned when order, stock and customer flows cross several systems. Data cleanup is often underestimated, especially when product, customer and order data are migrated from an older store. Custom module compatibility is the most expensive surprise at upgrade time, so inventory every custom module and check it against each target release line before committing to a schedule. Performance testing under realistic peak traffic is the last gate and needs its own environment. Ask each vendor, including DeployOpen, to put timelines, acceptance criteria and the testing scope into the fixed-scope written plan before work starts, since that document is where these durations should be agreed.
Questions buyers ask before choosing between Magento and PrestaShop
How much effort does each platform need to run and upgrade yourself?
Magento Open Source usually needs more ongoing effort because its supported stack is larger and tied to a fixed set of versions. Adobe's requirements for 2.4.9 list PHP 8.5, MariaDB or MySQL 8.4, OpenSearch 3, Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30, and Adobe supports only the listed combinations. PrestaShop 9 publishes lower minimums, including MySQL 5.7 or MariaDB 10.2, Apache 2.4 or nginx, and a memory_limit of at least 512M, so check those floors against your catalog size and traffic. Effort recurs with every patch cycle on both sides. The cost most teams underestimate is regression testing of your own modules and theme on each upgrade, so inventory them before you compare quotes. Source: PrestaShop 9 system requirements.
Can a small team operate Magento's service stack in-house?
A small team can, but only if each service has a named owner and the patch routine is scheduled rather than improvised. Magento Open Source 2.4.9 depends on OpenSearch, RabbitMQ, Valkey, PHP-FPM, a database and a web server, and Adobe documents Varnish as the full-page cache for self-managed installations. Each service needs version tracking, backups, monitoring and restart procedures. Adobe's lifecycle policy gives 2.4.9 standard support until May 31, 2029, so the line you choose sets how long you can stay on it without a major move. A team with little ecommerce operations experience should expect to need outside help for the first upgrade. Decide in writing which tasks stay with your staff and which move to a retainer.
How do the API models differ for integrations with an ERP or PIM?
The two platforms expose data differently, so the integration design depends on which model your middleware can call. PrestaShop's webservice gives third-party tools CRUD access to products, orders and customers using access keys. PrestaShop 9 adds an Admin API built on API Platform with OAuth2 authentication, multi-shop support and Swagger documentation. Magento Open Source's integration surface is built around its REST and GraphQL interfaces, and 2.4.9 makes the clearCart GraphQL mutation available in Open Source, which was previously Adobe Commerce only. Confirm that each endpoint covers the objects your ERP or PIM needs, including stock, pricing rules and customer groups, before you choose. Ask for a sample integration test as part of the scope.
Does OSL-3.0 mean the same obligations for custom code on both platforms?
Both cores use OSL-3.0, but your obligations depend on what you modify, how you distribute it and how each added module is licensed. PrestaShop's LICENSE.md file places its modules under AFL-3.0, and Magento's distribution also includes AFL 3.0. Custom code in a separate module, theme or integration may carry different terms from the core it extends. Ask counsel to review three points: whether your work is a derivative of the core, what your contracts with merchants say about source disclosure, and whether any purchased extension has terms that conflict with your plans. Those are legal questions. DeployOpen does not provide legal advice, so bring the answers into the written scope before development starts.
What does the upgrade cadence mean for planning a store?
Plan around support end dates and the annual patch window, not around individual releases. Adobe gives each 2.4.x release three years of standard support from general availability. Support for 2.4.7 ends May 31, 2027, 2.4.8 on May 31, 2028 and 2.4.9 on May 31, 2029. Adobe ships a full patch for its LTS line each May and releases security patches at least annually for supported lines. On the PrestaShop side, 9.0 reached its first stable version on June 10, 2025, and 9.2.0 was published on September 30, 2026, while the 8.x line still received 8.2.8 on August 18, 2026. Confirm the end-of-support date for the 8.x and 9.x lines with PrestaShop before you set a calendar. Source: Adobe Commerce lifecycle policy.
Should we hire outside help, and what does the work need from us?
Hire outside help when the upgrade, integration or hardening work exceeds the capacity or experience of your internal team. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades can run as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Your side typically supplies hosting access, a decision owner for requirements, an inventory of extensions and integrations, representative test data and named staff who accept each deliverable.
What should a written scope for either platform include?
A written scope should name the work, the platform version line and the boundaries that make a quote comparable. Include these parts:
- The target platform, version line and the support window you expect to hold.
- An inventory of modules, extensions and themes, with the license of each one.
- The integrations and API endpoints in scope, and the data each one reads or writes.
- The hosting stack, the services in it and who operates each one after handover.
- The data migration boundary, including what is excluded.
- Test and acceptance criteria, with named acceptance owners.
- Recurring responsibilities for patches, backups and upgrades, separated from the one-time build.
Ask each bidder to price the one-time work and the recurring support separately, so you can compare total cost of ownership over the support window.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Magento Open Source vs PrestaShop decision, we start by mapping your catalog, integrations and hosting constraints before any platform choice is treated as final.
How we scope
- We confirm catalog size, order volume, payment and ERP integrations, and the team that will run the store after launch.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We document the hosting stack each option needs, including PHP, database, search, cache and queue services, so the quote reflects real requirements.
How we build
- We implement the chosen platform in your infrastructure, with the module or extension choices recorded and justified against licensing terms.
- We test checkout, custom modules and webservice or API integrations, including PrestaShop's webservice and Admin API where they apply.
- We configure caching, search and security headers, then run security testing of the storefront, admin area and APIs before go-live.
How we hand over
- You receive architecture notes, configuration records, runbooks and the upgrade path for the release line you select.
- We document the steps for applying patches and moving between supported release lines, including what must be retested.
- Compliance evidence and controls are prepared for your assessors, though audit reports and certifications come from independent bodies.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped to your release calendar.
- Retainers can cover backups, patch application, dependency updates and periodic security testing for the live store.
- Before any major upgrade, we agree the scope and testing plan in writing so the cost and effort are visible up front.
