WooCommerce vs OpenCart: when each one fits a small or mid-size shop
WooCommerce fits teams already invested in WordPress, and OpenCart fits teams that want a standalone cart. Both are GPL-licensed and self-hosted, so the licence rarely decides this. The decision turns on five drivers: the skills your team already has, the extensions your catalog and checkout need, which version lines the vendor keeps maintained, the hosting footprint you can run, and who supports a third-party module when it breaks.
Start with skills and hosting. WooCommerce runs inside WordPress, so a team that already maintains WordPress sites, themes and plugins can reuse that work, but it also inherits WordPress update cadence and plugin sprawl. WooCommerce lists PHP 8.3 or greater, MySQL 8.0 or MariaDB 10.6 or greater, WordPress 6.9 or greater and a 256 MB memory limit as recommendations, so confirm those against the host you intend to use. OpenCart needs PHP 8.0 at minimum, and its development Docker setup defaults to PHP 8.4 with MariaDB. A shop with no WordPress footprint may find a single-purpose cart simpler to keep running.
Then test the extension path before you commit. List every module you need for payments, shipping, tax and accounting, and for each one confirm the maintainer, the supported version line and who answers when it fails. The OpenCart README closes bug reports about third-party modules and directs users to the extension developer, the forum or a commercial partner, so budget for that support route explicitly. Ask WooCommerce partners and your extension vendors the same question and get the answer in writing. Agree on upgrade ownership for each module before go-live.
Which platform fits which shop: WooCommerce vs OpenCart by scenario
This table matches common shop profiles to the platform that usually fits better and names the condition that makes it so. Read each row against your own content stack, team skills and catalog size, since the better fit often depends on one or two factors. Neither platform is the default choice for every shop.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Existing WordPress content site adding a store | WooCommerce | Your editors already work in WordPress and content, product pages and the shop should share one admin, one theme and one hosting stack. |
| Catalog-led shop with no WordPress footprint | OpenCart | You want a standalone PHP cart with no WordPress layer to patch, and the team will run only commerce software on the server. |
| Strong PHP team with no WordPress experience | OpenCart | Your developers can extend a PHP cart directly, but WooCommerce would add WordPress hooks, themes and plugin conventions they must learn first. |
| Shop needing many payment or shipping modules | Depends on the modules you need | Confirm each required gateway and carrier exists for your platform and version, and check its maintainer. OpenCart lists more than 13,000 modules and themes on opencart.com, but quality varies by developer. |
| Shop wanting a fully hosted option | OpenCart | OpenCart Cloud is offered by opencart.com as a hosted alternative to self-hosting, with multiple plans. Ask which plan covers your extensions and data location. |
| Shop that wants to self-host on its own cloud account | Either, with matching ops skills | Both are GPL-licensed and run on PHP with MySQL or MariaDB. Your choice depends on whether your operators know WordPress or plain PHP hosting. |
| Shop with large order volume expected to grow | WooCommerce | WooCommerce documents High-Performance Order Storage, enabled by default for new installs from 8.2, which keeps orders in dedicated tables. Confirm load testing for your own volumes. |
| Shop where third-party module bugs must be fixed quickly | Depends on support contract | OpenCart closes bug reports about third-party modules and points users to developers, the forum or a commercial partner. WooCommerce extensions are supported through their vendors and the WooCommerce.com premium support portal. |
How WooCommerce runs on WordPress and how OpenCart runs standalone
WooCommerce asks you to host a WordPress site with a plugin layered on top, so the WordPress core, the plugin and your theme all share one runtime. OpenCart asks you to host a single PHP application with its own admin and extension layer. The cards below cover the parts an operator maintains in each model and the checks to run before you commit.
PHP runtime and version support
WooCommerce recommends PHP 8.3 or greater, and the WooCommerce server requirements note that legacy environments may run PHP 7.4 or later, which is end of life and carries security risk. OpenCart's README lists a minimum of PHP 8.0, so an OpenCart host can run an older PHP line than WooCommerce's recommendation. Confirm the PHP version your chosen release supports, and plan the upgrade path, because WooCommerce and WordPress extensions often pin you to a PHP floor that moves with each release.
Database and order storage
WooCommerce runs on MySQL 8.0 or later or MariaDB 10.6 or later. From WooCommerce 8.2, High-Performance Order Storage is stable and enabled by default for new installations, keeping orders in dedicated tables such as wc_orders and wc_orders_meta. Existing stores that predate the default need a deliberate migration, and any custom code or plugin that reads order tables directly must be checked against it. Ask your OpenCart integrator which schema and database versions the chosen release targets.
WordPress core and plugin layer
WooCommerce is a plugin, so every store also inherits the WordPress core, its theme and its plugin set as operator responsibilities. A WooCommerce update can depend on a specific WordPress minimum, and a theme or payment plugin can block either one. Map which components are commerce-critical, test WordPress and WooCommerce updates together in staging, and confirm who owns each plugin's support after a break.
Standalone admin and extension layer
OpenCart ships its own admin area, catalog and extension framework, so there is no outer CMS to coordinate with. Payment gateways, shipping modules and themes install as OpenCart extensions, and the OpenCart README notes that feature releases add these modules. Inventory every extension in use, record its developer and compatibility notes, and decide before launch who patches or replaces an extension the core team does not maintain.
Web server, HTTPS and memory limits
WooCommerce requires HTTPS support and recommends a WordPress memory limit of 256 MB or more. OpenCart's Docker development environment pairs PHP 8.4 with MariaDB, which is a useful reference for local testing but is not a production instruction. Decide your web server, certificate handling and PHP-FPM sizing from the vendor requirements for your exact release, then load test the checkout path, since payment and order plugins drive most of the resource use.
Upgrade and security release cadence
WooCommerce moves quickly, with WooCommerce 11.2.1 published two days after 11.2.0 on October 9, 2026. OpenCart publishes 3.0.x and 4.x patches together, and its README treats patch versions as safe to apply. Set a written patch window for each stack, keep a rollback plan, and confirm which release lines receive security fixes before you pick a version line to standardize on.
WooCommerce vs OpenCart side by side on licensing, runtime and APIs
This table sets WooCommerce and OpenCart against each other on license, current release references, runtime requirements, order storage, API access and how extensions are sold and supported. Read each row as a question to confirm for the exact version you plan to deploy, since minimum requirements change between releases. The main takeaway is that both are GPL-licensed and self-hostable, but they differ in how their extensions and support paths are structured.
| Area | WooCommerce | OpenCart |
|---|---|---|
| License | GNU General Public License version 2 or later (GPL-2.0-or-later), per the license.txt file in the WooCommerce repository | GNU General Public License version 3 (GPL-3.0), per the LICENSE.md file in the OpenCart repository |
| Current release reference | WooCommerce 11.2.1, published October 9, 2026, two days after 11.2.0 | OpenCart 4.1.0.4 and 3.0.5.1, both published August 11, 2026, so the 3.0.x and 4.x lines are receiving releases together |
| Minimum PHP | PHP 8.3 or greater recommended; legacy environments may run PHP 7.4+, which is end of life | Minimum PHP 8.0 in the README; the Docker development environment defaults to PHP 8.4 |
| Database and memory | MySQL 8.0+ or MariaDB 10.6+, WordPress 6.9 or greater, 256 MB or more WordPress memory limit, HTTPS support | MariaDB is the default in the Docker development environment; confirm the supported database versions for your release in the OpenCart documentation |
| Order storage | High-Performance Order Storage is stable and enabled by default for new installations since WooCommerce 8.2, using tables such as wc_orders and wc_orders_meta | Orders are stored in the OpenCart application database; confirm the schema and any reporting or archiving approach with your chosen version |
| REST API access | wc/v3 namespace on the WordPress REST API, authenticated with API keys over HTTPS or OAuth 1.0a | Confirm the API surface, authentication method and version coverage for your release before designing integrations |
| Extension marketplace | Core plugin and extensions share a monorepo; WooCommerce.com sells themes and extensions with a premium support portal for buyers | Marketplace of more than 13,000 modules and themes, per opencart.com; the README directs users with third-party module issues to the developer, the forum or a commercial partner |
| Support path for third-party modules | Premium extensions sold through WooCommerce.com route support to the vendor portal; confirm each extension's support terms | Bug reports about third-party modules are closed by the core project, so support depends on the extension developer or a paid partner |
| Update model | Patch and feature releases follow WordPress and WooCommerce version requirements; test extensions against each target version | Patch versions are considered safe to update to, while feature releases add payment gateways and shipping modules, so plan extension retesting for feature releases |
What each license allows and what is paid for
WooCommerce is licensed under the GNU General Public License version 2 or later, as stated in the license.txt file of the WooCommerce repository. In practice, that means you can download the core plugin, install it on your own servers, change it for your own shop and redistribute modified copies under the same license terms. The license covers the code you receive. It does not cover services, hosting or the support contracts you buy from third parties.
- Self-hosting: The core plugin runs inside a WordPress installation you control, so there is no per-store license fee for the core itself.
- Modification: You may change the core for your own use. Modified copies you distribute must carry GPL terms, which matters if you ship a custom build to clients.
- Recurring cost: Hosting, PHP and database upgrades, backups and developer time are the main ongoing costs, and they are paid to your own providers or partners.
- Premium products: Paid extensions and themes sold through WooCommerce.com are separate purchases with their own terms, so the GPL on the core does not decide what you owe for them.
- Support path: Customers who bought themes or extensions are pointed to the WooCommerce.com premium support portal.
Before you commit, confirm the current license terms of every paid extension and theme on your shortlist with the vendor, including whether updates and support are included, for how long and for how many sites.
OpenCart is licensed under the GNU General Public License version 3, per the LICENSE.md file in its GitHub repository. The project describes itself as an open-source and free eCommerce platform, and opencart.com states zero monthly fees along with free downloads and updates. For a team that will self-host, the core cart itself carries no subscription, so budget mainly goes to hosting, implementation, and the modules you add.
- Free core: Downloads and updates of the core platform are described as free on the project home page.
- GPL-3.0 terms: You may run, modify and redistribute the code under GPL-3.0 conditions, which apply to distributed modifications.
- Marketplace modules: The site describes more than 13,000 modules and themes, and each one carries its own developer's license and terms.
- Hosted alternative: OpenCart Cloud is a fully hosted version offered in multiple plans, which replaces self-hosting with a recurring subscription.
- Recurring cost: Hosting, PHP upgrades, module maintenance and developer time remain yours under self-hosting.
Ask the OpenCart team or the module developer to confirm license terms, update policies and support for each module before purchase, and check whether the OpenCart Cloud plans fit your data and hosting requirements.
Both platforms separate the free core from the commercial layers around it. The paid part is rarely the platform license itself. It is the extensions, themes, hosted services and the people who maintain them. Treat each add-on as a separate contract with its own license, renewal terms and support window, and track them the same way you track core software.
- Extension licenses: Each paid WooCommerce extension or theme has its own terms, which can differ in scope, site count and renewal.
- Third-party modules: OpenCart modules come from many independent developers, so terms, update cadence and support quality vary widely.
- Bug reports: The OpenCart README closes bug reports about third-party modules and directs users to the extension developer, the forum or a commercial partner.
- Compatibility: An add-on that falls behind a core release can block upgrades, so its license and maintenance commitment affect your upgrade cost.
- Licensing changes: Ask vendors how renewals, price changes and end-of-support are handled before you build around a module.
For every add-on on your list, record the license type, what the license covers, the update and support window, and who you contact when it breaks.
How support works when a third-party module breaks
On OpenCart, a broken third-party module is not the core project's problem. The OpenCart README says bug reports about third-party modules are closed and directs users to the extension developer, the forum or a commercial partner. That means the first call after a failed upgrade goes to whoever wrote the module, and if that developer has stopped maintaining it, you may have no route to a fix except a partner you hire or code you own. WooCommerce draws a similar line in its README: customers who bought themes or extensions are pointed to the WooCommerce.com premium support portal, while security issues in core go to Automattic's HackerOne program. Both platforms send extension problems back to the extension vendor, so the difference lies in how much of the extension ecosystem is backed by a paid, supported channel.
For a shop that depends on several extensions, the risk compounds. Each module carries its own developer, release cadence and compatibility promises, and a core update can break any of them at once. Before you buy an extension on either platform, confirm who maintains it, how often it has shipped releases in the past year, and which platform version it declares support for. Ask the vendor in writing whether the module is tested against the version you run now and the version you plan to move to, and whether there is a named contact for defects. Record the answers in your change log so the next upgrade starts from a known list of extensions and owners.
Plan for the case where an extension is abandoned. Keep a staging copy of the store, run a regression pass on checkout, payments, tax and shipping after each core or module update, and keep a rollback path that includes a database backup. Decide in advance whether you would replace the module, fork it under its license, or pay a partner to maintain it. Confirm these points with each vendor and with your implementation partner before you commit, because the OpenCart README and the WooCommerce README do not promise a fix time or a support tier for third-party code.
What drives the running cost of each platform
Running cost is set less by the license than by who maintains the stack, which extensions are in play and how often the shop must be upgraded and retested. Both platforms are free to download, so the cards below sort the recurring and one-time costs that appear on either side of the comparison.
Hosting and PHP runtime
Both platforms run on PHP, so the host must meet each application's PHP floor. WooCommerce's server requirements recommend PHP 8.3 or greater, and the OpenCart README sets a minimum of PHP 8.0. A shop on WooCommerce may need a larger host to meet the 256 MB WordPress memory recommendation. Ask the hosting provider to confirm PHP version support and the upgrade path for each stack before you commit to a plan.
Database and order storage
Order volume drives database load and backup size. WooCommerce can store orders in dedicated tables through High-Performance Order Storage, which has been enabled by default for new installations since WooCommerce 8.2. OpenCart uses its own schema on MariaDB or MySQL in its Docker setup. Ask for a backup and restore test on the database alone, and confirm which tables hold orders so that database work is scoped correctly.
In-house skills and staffing
Most of the recurring cost is people time. WooCommerce asks a team to handle WordPress hosting, theme and plugin conflicts, and the WooCommerce data layer. OpenCart asks a team to handle its admin, its PHP codebase and its extension system. Count the staff hours each platform needs per month and decide whether that work stays in-house, goes to a retainer, or moves to a vendor. Ask any partner to state which skills are covered in the scope.
Paid extensions and licenses
Free core downloads do not mean free shops. Payment, shipping, tax and accounting connectors often carry annual license fees, and each has its own update schedule. OpenCart's marketplace lists more than 13,000 modules and themes, and WooCommerce extensions are sold separately through WooCommerce.com. Build a written list of every extension, its vendor, its license term and its renewal date, then compare that list across both platforms.
Upgrade and regression testing
Recurring effort is highest when a minor release breaks a payment or shipping module. Patch and feature releases move on separate schedules on both platforms. OpenCart publishes 3.0.x and 4.x releases in parallel, and WooCommerce ships frequent releases in its 11.x line. Budget a staging environment, a regression test plan covering checkout, refunds and tax, and time for each cycle. Request an upgrade test plan in the quote so the effort is visible before work starts.
Support contracts and implementation fees
Support for third-party modules sits outside the core projects. The OpenCart README closes bug reports about third-party modules and points users to the extension developer, the forum or a commercial partner. WooCommerce directs customers who bought extensions to the WooCommerce.com premium support portal. Implementation partner fees are one-time for the build and recur when a retainer covers upgrades and fixes. Ask each partner for a written scope, a named list of supported extensions and the response terms for module failures.
Moving a store from WooCommerce to OpenCart or back: what transfers and what is rebuilt
This sequence shows which parts of a store move cleanly between WooCommerce and OpenCart, which parts need mapping or rebuilding, and how to confirm the new store behaves correctly before customers are switched over.
Inventory the store before touching data
List every product, category, customer group, order, coupon, tax rule, shipping zone, payment method, extension, theme customization and external integration on the current store. Include the ERP, accounting, email, marketing and fulfillment connections, since these often hold the data that the storefront does not. Assign an owner to each item and note whether it is a data set, a configuration or a code dependency. The step is done when the store owner and the implementer sign off on one inventory that covers every system the store touches.
Map the data model and order statuses
Compare how each platform stores products, variants, options, customers, addresses and orders, and document the field-by-field mapping. Pay particular attention to order storage: WooCommerce stores orders in dedicated tables when High-Performance Order Storage is enabled, which is the default for new installations from version 8.2, while the storefront schema of OpenCart differs. Build a table that maps each WooCommerce order status to an OpenCart order status, and decide in advance how statuses with no direct equivalent will be handled. The step closes when the mapping is written down and reviewed by someone who runs fulfillment and customer service.
Audit extensions and classify each one
Sort every plugin or module into three groups: available on the target platform with comparable behavior, available with different behavior or configuration, or with no equivalent. Check each candidate on the target marketplace and confirm its maintenance status, supported versions and license with the vendor, because listings alone do not show whether a module is still maintained. Items with no equivalent become scoped rebuild work, and items that only exist as custom code on the source platform need a written specification before work begins. The step is done when every extension has a classification and an owner.
Rebuild the gaps and integrations
Build or configure the extensions with no equivalent, and rebuild the integrations that connect the store to other systems. Where WooCommerce exposes its REST API under the wc/v3 namespace, confirm which endpoints the integrations use and whether the target platform offers equivalent endpoints or requires a new connector. Test each integration against a staging copy with sample data that matches production. The step closes when each integration has been exercised end to end and its failure behavior is documented, including what happens when a module is abandoned by its developer.
Migrate and reconcile test data
Run a test migration of catalog, customers and historical orders into a staging environment, then reconcile counts and totals against the source system. Check product images, URLs, customer password handling, stock levels and tax calculations on a sample of records, and record every exception. Repeat the migration until the exception list is short and each remaining item has an agreed decision. The step is done when the reconciliation report is signed by the store owner and the person responsible for finance.
Test payments, shipping and tax
Run test transactions through every payment gateway on the staging store, including successful payments, declines, refunds and partial captures where the gateway supports them. Verify shipping rates, carrier integrations, pickup options and address validation for each zone you serve, and check tax rules against the jurisdictions in scope with your tax adviser. Confirm webhook or callback endpoints point to the new environment and that fraud and dispute handling still works. The step closes when a written test log shows each path passed or has a documented fix.
Plan the cutover and redirects
Agree the cutover window, the freeze on catalog and order changes, the final data delta sync and the rollback conditions with the business owner. Build a redirect map from every indexed URL on the old store to its equivalent on the new one, including category, product, filter and blog URLs, and test it against a crawl of the live site. Update DNS, email sending domains, analytics tags and payment webhook addresses in the same change plan. The step is done when the rollback path has been rehearsed and the redirect map has been tested with no unexpected 404 responses on the sampled URLs.
Confirm the store after go-live
Monitor orders, payment success rates, error logs, search console reports and customer support tickets for the period agreed in the cutover plan. Compare live order counts and revenue with the source system's last known figures to confirm nothing was dropped during the switch. Keep the source store readable and retained under the agreed archive policy until the business confirms it is no longer needed. The step closes when the business owner signs off on the post-launch checks and the archive decision is recorded.
Where WooCommerce and OpenCart projects usually run long
On both platforms, the schedule slips less in the storefront build than in the work around it: payment and shipping integrations, tax rules, catalog import and the first upgrade after go-live. For WooCommerce, the common long runs are extension conflicts after a core release, since each store may depend on a different set of plugins from different vendors that must all be tested together. For OpenCart, the equivalent risk sits in extensions that bundle payment gateways and shipping modules, which the project README says arrive with feature releases. Ask the implementation partner to list every payment, shipping, tax and import module by name, version and author before the scope is signed, and to state which of them will be tested against each upgrade.
Hosting setup is where legacy environments cause the most delay. WooCommerce recommends PHP 8.3 or greater and MySQL 8.0+ or MariaDB 10.6+, and its server requirements note that older PHP 7.4 and MySQL 5.6 environments are end of life. OpenCart's README sets a minimum of PHP 8.0, and its development environment defaults to PHP 8.4 with MariaDB. A shop that inherits an older host, or a PHP version pinned by another application on the same server, can add weeks of remediation before any store work starts. Confirm the target PHP and database versions in writing, who provisions them, and whether the existing host is in scope for upgrade.
Custom integrations are the other frequent source of overrun. WooCommerce exposes orders and products through the wc/v3 REST API, authenticated with API keys over HTTPS or OAuth 1.0a, so an ERP or fulfilment sync needs key management, rate handling and error retries designed up front. On OpenCart, custom work usually lives in modules that must be re-checked after every feature release. The OpenCart README closes bug reports about third-party modules and directs users to the extension developer, the forum or a commercial partner, so the written scope should name who owns fixes for each module, who signs off test results, and what happens when a vendor stops maintaining one.
Questions buyers ask before choosing WooCommerce or OpenCart
What drives the total cost of running WooCommerce or OpenCart in-house?
Both platform licenses are free under GPL terms, so the cost sits in hosting, extensions or themes, developer time, and ongoing maintenance. Hosting and extensions recur every year, while setup and customization are usually one-time work. WooCommerce costs rise with the number of plugins, payment gateways and integrations you need, and with the traffic and order volume your database and PHP hosting must handle. OpenCart costs rise with the modules you buy from its marketplace and any custom theme work. When you request a quote, ask for each recurring item (hosting, licenses, extension renewals, support contracts) listed separately from one-time work (installation, configuration, data migration, testing).
How long does it take to launch a small store on each platform?
Launch time depends on the catalog size, the number of integrations, and how much design work is custom, so no single duration applies to both platforms. Ask any implementation partner for a written timeline tied to a fixed scope, and check that it covers product import, tax and shipping rules, payment testing, and order flow testing before go-live. WooCommerce projects often spend time on theme and plugin selection, since the plugin ecosystem is large and choices must be checked against each other. OpenCart projects often spend time on extension compatibility checks and theme adjustments. Confirm which of these steps are included in the fixed scope.
What skills does my team need to run WooCommerce or OpenCart?
Your team needs someone who can administer a PHP web application, a relational database and a web server, plus someone who handles store operations such as products, orders and refunds. WooCommerce also requires familiarity with WordPress itself, since WooCommerce runs as a plugin inside it. The WooCommerce server requirements recommend PHP 8.3 or greater, MySQL 8.0+ or MariaDB 10.6+, WordPress 6.9 or greater and a WordPress memory limit of 256 MB or more, all with HTTPS. OpenCart's README shows a minimum PHP version of 8.0. Ask your implementer which of these skills they will cover during the engagement and which you must keep in-house afterward.
Can a small team run either platform without outside help?
A small team with solid web administration skills can run either platform, provided it accepts a steady maintenance routine. The work includes applying patch releases, backing up the database and files, testing updates in a copy of the store, and watching payment and tax settings after each change. OpenCart's README describes patch versions as safe to update to, and both product lines publish regular releases, so a schedule matters more than the platform choice. Outside help is most useful for initial hardening, payment integration, and the first major or minor upgrade. Ask whether the scope includes handover documentation and a written upgrade runbook.
How do upgrades and extension compatibility work on each platform?
WooCommerce is maintained as a WordPress plugin, and its extensions and themes are developed separately, so each upgrade needs a check of every installed plugin against the new core version. OpenCart uses a MAJOR.MINOR.FEATURE.PATCH version scheme, and its README says patch versions are considered safe to update to, while feature releases add extensions such as payment gateways and shipping modules. OpenCart's README also says bug reports about third-party modules are closed and directs users to the extension developer, the forum or a commercial partner. In both cases, ask your partner to keep an inventory of extensions, test each upgrade in staging, and define who fixes a broken module.
Who supports me when a third-party module breaks?
Support for a broken third-party module usually comes from its developer, not from the core platform team. OpenCart's README closes bug reports about third-party modules and points users to the extension developer, the forum or a commercial partner. The WooCommerce README points customers who bought themes or extensions to the WooCommerce.com premium support portal, and it reports core security issues through Automattic's HackerOne program. Before you select extensions, confirm each developer's support terms, last update date and compatibility statement for your version. In a quote, ask whether the implementer will diagnose module faults and whether that work is in scope or billed separately.
When should a shop hire outside help instead of doing the work internally?
Hire outside help when the store handles regulated or high-value payments, needs custom integrations with an ERP or warehouse system, or lacks anyone who can respond to a failed upgrade within a working day. Outside help is also worth considering before a platform migration or a shift to a larger hosting setup. Ask any firm for a written, fixed scope that names deliverables, testing steps, handover material and what is excluded. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and offers ongoing support and upgrades as retainers. It does not publish a price list, and a quote follows from the written scope.
How DeployOpen helps choose, implement or migrate a self-hosted store
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. For a WooCommerce or OpenCart decision, that means working from your catalog, payment and shipping requirements, and hosting constraints to a written scope before any build starts.
How we scope
- We review your catalog size, payment and shipping integrations, and required extensions before recommending either platform.
- The written scope names which WordPress plugins or OpenCart modules are in use and who owns each one.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We confirm your PHP, database and hosting targets against each platform's current requirements before quoting.
How we build
- We install and configure the chosen platform inside your infrastructure, following your hosting and network rules.
- We customize themes, integrate payment gateways and order systems, and document any third-party module we add.
- We test checkout, order flows, and upgrade paths in a staging environment before anything reaches production.
- Where an extension is unmaintained or breaks, we assess the fix, the alternative, or the cost of replacing it.
How we hand over
- You receive documentation covering configuration, extensions, backup routines, and the upgrade procedure for your store.
- We walk your team through the update process for WordPress, WooCommerce, OpenCart, and their extensions.
- Backups and restore steps are tested and written down so your staff can run them without us.
- Handover records list every module, its source, its license, and its named maintainer or support route.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover scheduled platform updates, extension compatibility checks, and security testing of the storefront.
- Ask in your quote which upgrades, extension checks, and response paths are included and which are billed separately.
- Support scope is set in writing, so the division of work between your team, DeployOpen, and extension vendors is clear.
