Migrate from BigCommerce to WooCommerce: what the move involves
The move is a data, integration and hosting project on WordPress. Most merchants arrive here because of a BigCommerce renewal, a plan or pricing change, a data residency requirement or concern about lock-in. Moving to WooCommerce means your catalog, customers and order history leave BigCommerce, your app-based features are rebuilt as WordPress plugins, and the store runs on hosting you choose and maintain. The product side is comparatively simple, but the store only goes live when the data, the integrations and the hosting are all in place and tested. The work is usually done by an in-house platform or store team with an implementation partner. The in-house team owns the business decisions: which products, customer fields and order data must carry over, which BigCommerce apps are essential, and who signs off on checkout and tax behavior. The partner or internal engineers typically handle the catalog extraction through the Catalog API within your plan's rate limits, the import through the WooCommerce REST API, and the plugin selection and hardening. Ask any partner for a written scope that names each data set, each integration and each acceptance test before work begins.
Effort and risk depend mostly on catalog size, the number of BigCommerce apps in use, and how many custom integrations feed your ERP, warehouse or payment tools. Each of these adds extraction, mapping and testing work, and the cost is largely one-time, while hosting, plugin licenses and maintenance recur. Plan for the risks that are specific to this move: order and customer data must be reconciled, URLs and search rankings must be preserved with redirects, and payment and tax configuration must be verified on the new stack. Keep the BigCommerce store live until the new store has been validated end to end. Finally, confirm the platform requirements before you commit. WooCommerce recommends 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, and you must keep these current. Ask your hosting provider and your implementation partner who applies WordPress, WooCommerce and plugin updates, and who monitors security advisories. Those answers determine your long-term operating burden more than the initial import does.
Which BigCommerce capabilities map to WooCommerce, and what needs rework
This table maps common BigCommerce capabilities to WooCommerce core, plugins or custom code, and labels each as clean, needs rework or gap. WooCommerce core is GPL-2.0-or-later, but many commerce features depend on extensions whose licenses and coverage you must check yourself. Use the table to scope the work, then confirm plugin coverage against your own catalog and store setup.
| BigCommerce capability | WooCommerce equivalent | Status and notes |
|---|---|---|
| Products and variants | WooCommerce core product types, including variable products with attributes | Clean for simple and variable products. Confirm variant count and option limits against your catalog. |
| Categories and brands | Core product categories; brands through a brand taxonomy plugin or core support where available | Needs rework. Brands are not a core concept in every WooCommerce setup, so confirm a plugin before import. |
| Bulk pricing rules | Core scheduled sale prices; tiered or quantity pricing needs a paid or third-party extension | Gap in core. Confirm the extension covers your rule types, such as customer group or quantity tiers. |
| Custom fields and metafields | Product meta data and custom taxonomies, usually handled by a custom fields plugin or small plugin code | Needs rework. Map each field to meta keys or taxonomies and test display on the storefront theme. |
| Customer accounts | WordPress users with WooCommerce customer roles, imported through the REST API or a custom script | Needs rework. Passwords cannot be exported in usable form, so plan password reset emails or account claim flows. |
| Orders and order history | Orders stored in WooCommerce order tables, with High-Performance Order Storage on by default for new installations | Needs rework. Historical orders usually import through the API or custom code, and you must confirm the status and tax mapping. |
| Checkout and payments | Core checkout with payment gateway plugins; gateways are separate plugins from different vendors | Needs rework. Each gateway has its own license, fees and PCI DSS scope, so confirm it with your payment provider. |
| Apps | Plugins from WooCommerce.com or the WordPress plugin directory, or custom plugin code | Needs rework. Most BigCommerce apps have no direct equivalent, so list each app and assign a plugin or build decision. |
| Product reviews | Core product reviews, with ratings and moderation in the WooCommerce admin | Clean for basic reviews. Import of existing reviews usually needs a script or plugin. |
| Search | WordPress and WooCommerce product search, with faceted search through an extension or a search service | Gap for advanced faceted search in core. Confirm the search plugin handles your filters and index size. |
Which data and integrations to extract and rebuild
A BigCommerce to WooCommerce move has two kinds of work: moving records and rebuilding connections. Records such as products, customers and orders can be extracted and imported, while ERP, payment, shipping, tax and marketing links are separate projects that need their own design and testing.
Catalog extraction through the Catalog API
The Catalog API covers products, categories, brands, variants, images, custom fields and metafields, which gives a programmatic path for pulling the full catalog. Extraction must be paced within your plan's API rate limits, so large catalogs need a throttled, resumable script. Check that variant option sets, bulk pricing rules and custom field values are captured, because WooCommerce models them differently and each needs a mapping decision.
Import through the WooCommerce REST API
WooCommerce exposes its REST API under the wc/v3 namespace, authenticated with API keys over HTTPS or OAuth 1.0a. Your import script creates products, variations and categories in that order, then writes the BigCommerce product IDs into a mapping table so reruns update rather than duplicate. Confirm which key scope your import account holds and test the script on a staging store first.
Customers and order history
Customer records and past orders are usually exported separately from the catalog. Confirm with your team which order history must appear in the new store and which can stay in an archived export, since imported orders affect reporting and customer accounts. Check how password hashes are handled: most platforms do not export them, so customers may need to reset passwords on first login.
Payment and checkout connections
Payment gateways are not copied with the catalog. Each gateway must be connected to WooCommerce, tested in sandbox mode and checked for card token handling, because stored card data generally cannot move between providers. Plan the cutover so pending transactions and subscriptions are settled or moved before the old store closes.
Shipping, tax and ERP integrations
Shipping carriers, tax calculation services and ERP or warehouse systems connect to BigCommerce through apps or custom API calls, and none of these links move automatically. Each one needs a WooCommerce plugin or custom integration, a field mapping and an end-to-end test using real order flows. Ask each vendor whether they support WooCommerce and what their setup and recurring fees are.
Marketing and analytics tags
Email platforms, review tools, analytics tags and advertising pixels were often installed as BigCommerce apps or scripts. Inventory every tag and integration before cutover, decide which to keep, and confirm that consent settings still apply on the new storefront. Missing tags are easy to overlook and can break attribution and abandoned cart emails for weeks.
The migration sequence from inventory to decommission
This sequence moves a BigCommerce store to WooCommerce in controlled stages, so each stage produces an artifact the next one depends on. The BigCommerce store stays live until the cutover checklist is signed off, and it is switched off only after the parallel run has reconciled products, customers and orders.
Inventory data, apps and integrations
List every product, variant, category, brand, customer segment, order type, custom field and metafield in the BigCommerce store. Record each installed app, each storefront script, each payment and shipping integration, and each external system that reads or writes store data, such as ERP, email or analytics. The output is a migration inventory with one owner per integration and a written decision for each: rebuild as a WooCommerce plugin, replace with a service, or retire. The step is done when the business owner has signed off the list.
Build the field mapping sheet
Map each BigCommerce entity to its WooCommerce equivalent, including products to simple or variable products, option sets to variation attributes, custom fields to product meta, and customer groups to roles or tags. Note fields with no direct match, such as certain bulk pricing rules, and decide how each will be handled. Confirm details of WooCommerce product and customer import behavior in the WooCommerce documentation and in your test store before relying on them. The output is a field mapping sheet reviewed by the developer who writes the import scripts and by the merchandising lead.
Extract the catalog through the Catalog API
Use the BigCommerce Catalog API to pull products, variants, images, categories and custom fields programmatically, paging through results and respecting the rate limits of the store's plan. Save raw responses before transforming them, so the extraction can be rerun and audited. Ask your developer to confirm the current limits for your plan on the BigCommerce developer documentation. The output is a versioned raw extract plus a count of records per entity, which becomes the baseline for later reconciliation.
Pilot import into a staging WooCommerce site
Import the mapped data into a staging WordPress and WooCommerce installation that matches the production PHP, MySQL or MariaDB and WordPress versions you plan to run. Import products and variations through the WooCommerce REST API using the wc/v3 namespace, then import customers and the category tree. Review a sample of products on the storefront for titles, prices, variants, stock and images. The output is a pilot import log and a list of defects, each assigned to a fix in the mapping sheet or the import script.
Run a parallel period with order reconciliation
Keep BigCommerce live as the system of record while the staging catalog is refreshed on a schedule and checked against the live store. Reconcile product counts, prices, stock levels and customer records, and compare orders placed during the parallel period with the same orders in WooCommerce, including tax, shipping and payment status. Investigate every mismatch to a cause. The output is a reconciled catalog report and an order reconciliation report, both signed by the store owner.
Build the redirect map and rehearse cutover
Export every BigCommerce product, category, brand and content URL, then map each one to its new WooCommerce address. Create 301 redirects for every changed path and test a sample of them on staging. Confirm with your SEO lead which URLs carry search traffic and must be checked first. Rehearse the cutover steps, including DNS changes, certificate issuance, email records and payment gateway callbacks. The output is a redirect map and a rehearsal log with timings observed in your own environment.
Cut over DNS and redirects
Freeze orders on BigCommerce, run the final incremental import, apply the redirect rules and switch DNS to the WooCommerce host. Verify HTTPS, checkout, payment callbacks, transactional email and search engine access from outside the network. Keep the BigCommerce store readable for an agreed period so that staff can check historical records. The output is a signed-off cutover checklist with a timestamp for each step and a named owner for each sign-off.
Decommission BigCommerce
After the agreed period and once all open orders, refunds and support tickets are closed, export a final archive of orders, customers, product data and configuration for your records. Cancel the BigCommerce subscription only after confirming the archive is complete and readable, and revoke all API keys and app credentials. Check the cancellation terms and any data retention notice with BigCommerce before the final date. The output is a decommissioning record that lists what was archived, where it is stored and who approved the shutdown.
What drives cost and duration in this migration
This table lists the components that move the cost and timeline of a BigCommerce to WooCommerce migration, who is paid for each, and what recurs after launch. Read it as a checklist for a written scope: each row names what to ask a partner or internal team to price separately.
| Driver | Who is paid for what | One-time or recurring | What to ask for in a written scope |
|---|---|---|---|
| Catalog size and variant complexity | Developer time for the extraction script, mapping of products, options and SKUs, and import validation | One-time, with re-runs for delta syncs before cutover | Product, variant and image counts, how option sets map to WooCommerce variations, and how many test imports are included |
| BigCommerce apps to replace | Plugin selection, configuration and any custom code for features the store relied on, such as reviews, subscriptions or shipping rules | Plugin licenses and support renew annually or monthly; one-time setup | An inventory of every installed BigCommerce app, the WooCommerce replacement for each, and which ones need custom code |
| Custom checkout and storefront work | Theme build or rebuild, template overrides, checkout hooks and payment gateway configuration | One-time build; theme updates and gateway fees recur | Whether the theme is custom or purchased, the list of checkout customizations, and which payment gateways must be connected |
| SEO URL volume | Mapping of category and product URLs, redirect rules, and checks in search console tools after launch | One-time mapping; redirect maintenance and monitoring continue after launch | Count of indexed URLs, the redirect map format, and how 404 errors will be tracked for the first months after cutover |
| Customer and order history | Export scripts, import into WooCommerce, and checks on how orders are stored in HPOS tables | One-time import; storage growth recurs with order volume | How many customers and orders will be imported, whether historical orders are needed in full, and the retention rule for personal data |
| Integrations | Connectors for ERP, shipping, tax, email and analytics, plus their testing | Connector licenses and API maintenance recur; build is one-time | A list of every system that reads or writes orders and products, with the API and authentication method each one uses |
| Hosting and staging setup | Server or managed WordPress hosting, a staging environment, backups and HTTPS configuration | Hosting and backups recur; staging is kept as long as changes are made | Required PHP, MySQL or MariaDB versions, backup frequency, restore testing, and who owns the staging and production accounts |
| Testing and cutover | Test plans, load checks, payment and tax testing, and the cutover window | One-time for launch; regression tests recur with each update | Test scope in writing, acceptance criteria, and a rollback plan that keeps the BigCommerce store live until sign-off |
| Ongoing updates and security patching | WordPress, WooCommerce and plugin updates, vulnerability review and incident response, by your team or a support retainer | Recurring for the life of the store | Who applies core and plugin updates, the response time for critical fixes, and the patching owner after handover |
How the move differs by store size and starting point
A small catalog with few installed BigCommerce apps is usually the simplest case. Extraction is often manageable with the built-in exports described in the BigCommerce export guide, because the product, customer and order files are small enough to review by hand. Fewer apps means fewer functions to replace, so most of the work goes into the theme and the checkout flow rather than into integrations. WooCommerce on a managed WordPress host is often sufficient at this size, and the hosting decision is mostly about support and backups rather than capacity.
- Extraction: Built-in CSV exports may cover products, customers and orders, so a Catalog API script may be unnecessary.
- Plugins: Each BigCommerce app should be matched to one WooCommerce plugin or a small set of free plugins before you commit.
- Hosting: A managed WordPress host with backups and staging is usually enough, and you should confirm its PHP and MySQL or MariaDB versions against the WooCommerce server requirements.
- Parallel run: A short side-by-side period is often practical, with the old store kept live until images and redirects are verified.
- Theme: Rebuilding a simple theme is often the largest single task.
Confirm with your developer which apps are truly in use, since unused apps can be dropped from scope.
A mid-sized catalog with many custom fields and bulk pricing rules raises the extraction effort. Custom fields, metafields and bulk pricing rules do not map one to one onto WooCommerce, so each one needs a decision about where it lives, such as product meta, attributes or a plugin. The BigCommerce Catalog API covers products, variants, images, custom fields, metafields and bulk pricing rules, which makes scripted extraction the practical route, but you must plan requests around your plan's rate limits. Expect a longer parallel run so that pricing and stock can be reconciled.
- Extraction: Script the Catalog API with paging, retries and logging, and test against a sample before the full pull.
- Mapping: Decide for each custom field and bulk pricing rule whether it becomes an attribute, custom meta or a pricing plugin.
- Plugins: Evaluate bulk pricing and B2B pricing plugins early, since they often drive the plugin list.
- Hosting: Choose capacity for imports and scheduled jobs, and consider High-Performance Order Storage on current WooCommerce versions.
- Parallel run: Plan a longer overlap period to reconcile prices, stock and orders.
Ask your team to produce a field-by-field mapping sheet before any import is run.
A store that already runs WordPress for content has a head start, since the hosting, PHP and database skills, and the admin habits, already exist. The main risk shifts from building a store to combining two sites. Content pages, blog posts and menus may overlap with product pages, and both need to share one set of URLs, one theme and one update process. Keeping WordPress and WooCommerce current is a shared responsibility, so the team should agree who applies updates before launch. Existing hosting may need upgrades to meet current PHP and database requirements.
- Hosting: Confirm the existing host meets the current PHP, MariaDB or MySQL and memory requirements, or plan an upgrade.
- Plugins: Check for conflicts between existing WordPress plugins and WooCommerce extensions before import.
- Updates: WordPress applies automatic updates to plugins and themes only in limited cases, so assign someone to review and apply extension updates.
- Extraction: Product and customer data still comes from BigCommerce, so the extraction work matches the catalog size.
- Parallel run: Staging the combined site often reduces the time the old store must run in parallel.
Confirm the WordPress version your host supports before you begin, and test the combined site on staging.
What usually goes wrong and how to prevent it
Most failed BigCommerce to WooCommerce moves fail in predictable places: URLs, extraction limits, data mapping and then the platform itself after launch. The cards below cover each risk, what to check before cutover, and how to keep the new store patched once it is live.
Lost URLs and rankings
Without a complete redirect map, every changed product, category and brand path becomes a 404 and search engines lose the signals attached to it. Export every indexed URL from the BigCommerce store and from your analytics or search console data, then map each one to its WooCommerce permalink before cutover. Test a sample of old URLs after launch and watch for unexpected 404s in the first weeks. Confirm the permalink structure you choose in WordPress before you write any redirects.
Rate-limit throttling during extraction
The Catalog API enforces request limits that depend on your plan, so a naive full export can stall or fail partway through. Build the extraction with pagination, retries with backoff and checkpoints so a restart resumes where it stopped. Confirm your current plan's limits in the BigCommerce developer documentation before you schedule the run, and extract during a window when the store is not also serving heavy API traffic from other integrations.
Variant and option mismatches
BigCommerce variants combine option sets, SKUs and per-variant prices, while WooCommerce variable products need matching attributes and variation records. Map each BigCommerce option set to a WooCommerce global attribute, then import variations and check that every SKU has one parent and the correct price. Compare counts of products and variations between the two stores in a test import before cutover, and sample products with unusual option combinations by hand.
Missing images and media
Product images are referenced by URL in the BigCommerce catalog, and a broken or incomplete image import leaves product pages blank even when the data is correct. Download each image, keep its filename and alt text, and import it into the WordPress media library with the product so the references resolve. Check that images for variants are attached to the right variation. Keep the original store live until every image has been verified in the new site.
Order and customer data gaps
Customer accounts, addresses, order history and open orders do not move cleanly through a generic product import. Decide which historical orders to keep, usually as read-only records or an archive, and confirm that WooCommerce stores them in the expected tables if High-Performance Order Storage is in use. Import customers with their contact details and check password handling, since most stores will need customers to reset their passwords. Reconcile order and customer counts after each test run.
Outdated PHP, MySQL or WordPress
WooCommerce and WordPress run on the PHP, database and WordPress versions you deploy, and running an older stack leaves known weaknesses in place. Confirm the current WooCommerce server requirements and the WordPress requirements before you choose a host, then pick a PHP, MySQL or MariaDB version within the recommended range. Do not carry over a legacy environment because a plugin is slow to update. Schedule a version review at least once a year and whenever a new WooCommerce or WordPress major release is published.
Unpatched plugins and updates
Plugins and themes are the most common entry point into WordPress stores, and WordPress applies automatic updates to them only in special cases. Inventory every plugin and extension that replaces a BigCommerce app, record its source and license, and assign someone to review its security advisories. Use a managed process that tests updates on a staging copy and keeps a rollback point, rather than relying on automatic updates alone. Report security issues in WooCommerce through the published channel, and confirm your extension support terms before buying.
Questions buyers ask before moving from BigCommerce to WooCommerce
What does a BigCommerce to WooCommerce migration cost?
The cost is driven by the work, not by a single fee: catalog extraction, data mapping, theme rebuild, replacing BigCommerce apps with plugins, redirects, testing and hosting. WooCommerce itself is free under the GPL, so the spend is on people, hosting, premium extensions, themes and support. Some of this is one-time (migration, theme build, testing) and some recurs (hosting, extension renewals, maintenance, security monitoring). Ask any vendor for a written scope listing each item, who performs it, and which recurring costs continue after go-live. DeployOpen does not publish a price list; a quote follows from the agreed written scope.
How long does a BigCommerce to WooCommerce migration take?
The timeline depends on catalog size, how many apps the store uses, how much of the theme must be rebuilt, how many URLs need redirects and how quickly the merchant team can review data. Catalog extraction is limited by BigCommerce API rate limits set by the plan, so large catalogs take longer to pull. Ask for a phased plan with a clear go-live checkpoint and a parallel-run period. Any duration you are given should be tied to a written scope and named assumptions.
What does the merchant team need to provide during the migration?
The merchant team needs to confirm which products, categories, customers and order history must move, which BigCommerce apps are in use, and which URLs earn organic traffic and must keep working. They also need to approve the product attribute mapping, the tax and shipping rules to be rebuilt, and the payment and checkout configuration. Named people should own sign-off on the catalog, the redirect map and the go-live decision.
Can our team migrate the store without a partner?
Yes, if the team has WordPress and WooCommerce experience and the catalog is small enough to handle with the built-in tools and the WooCommerce REST API. The harder parts are paging through the BigCommerce Catalog API within rate limits, mapping variants and custom fields, preserving SEO URLs with redirects, and replacing app functionality. A partner is worth considering when these steps need to be repeated, tested and documented for an audit or for a regulated business.
What hosting does WooCommerce require?
WooCommerce recommends PHP 8.3 or greater, MySQL 8.0+ or MariaDB 10.6+, WordPress 6.9 or greater, a WordPress memory limit of 256 MB or more, and HTTPS support. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater. Legacy versions such as PHP 7.4 and MySQL 5.6 are end of life and should not be used. Confirm the exact versions with your hosting provider and in the current WooCommerce server requirements before you choose a plan.
Who patches WooCommerce and WordPress after go-live?
The merchant or its operator patches WooCommerce, WordPress, the theme and every plugin, because the store is self-hosted. WordPress applies automatic major release updates to newly created sites by default and backports critical security fixes to older versions, but automatic plugin and theme updates happen only in special cases chosen by WordPress.org. Only the latest WordPress release is officially supported. Agree on a patch cadence, a staging test process, backup routine and an owner for each update before go-live. DeployOpen offers ongoing support and upgrades as retainers.
Will our customers and orders move with the store?
Customers and orders can be moved through exports and the API, but each record needs mapping to WooCommerce and WooCommerce stores orders in dedicated tables when High-Performance Order Storage is enabled, which is the default for new installations from WooCommerce 8.2. Passwords generally cannot be exported in readable form, so plan a reset flow for customers. Confirm with your developer which order statuses, tax data and historical records must be imported and how they will be verified.
Official sources for the migration work
The migration touches three sources of truth: the BigCommerce Catalog API that holds your catalog, the WooCommerce and WordPress documentation that governs the new store, and the security and upgrade policies that decide how long it stays safe. Check each one against your own plan, versions and hosting before you write any import code.
WooCommerce license terms
WooCommerce is licensed under the GNU General Public License version 2 or later, so the core plugin is free to run and modify. Read the license file to confirm which terms apply to any paid extensions, themes or add-ons you plan to buy, since those come from separate sources. Your legal or procurement team should record that review before the store goes live.
Server requirements
The server requirements page lists the PHP, MySQL or MariaDB, WordPress memory and HTTPS expectations for the store. Compare them with the hosting plan you are considering, because older PHP and database versions may still run the software but are end of life and create security exposure. Ask your host to confirm in writing which versions it will maintain.
REST API documentation
The wc/v3 namespace is the route your import scripts will use to create products, variants, categories and customers. Check the authentication options, API key scopes and the required WooCommerce and WordPress versions before writing code, and test writes on a staging copy first. Confirm which endpoints accept batch requests so you can size the import run.
High-Performance Order Storage
High-Performance Order Storage keeps orders in dedicated tables rather than the standard WordPress post tables. If you import historical orders, confirm whether the store uses this mode and whether your import and reporting tools read the correct tables. Decide early whether you migrate order history at all, since it affects database size and backup scope.
WordPress security and updates
The WordPress security page explains how fixes reach older releases and which versions receive support, while the upgrade guide explains automatic updates. By default, plugins and themes receive only selected automatic patches, so your team must own a patching schedule for WooCommerce extensions. Write that schedule into the operating runbook before cutover.
BigCommerce Catalog products API
The Catalog products API is the source for extracting your catalog, including variants, images and custom fields. Read its rate limits and pagination rules for your plan before planning the extraction window, and export a full snapshot before the store is changed or closed. Confirm which fields map to WooCommerce attributes, variations and metadata.
How DeployOpen works on this migration
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For a move from BigCommerce to WooCommerce, the work starts with a written scope that defines what leaves BigCommerce, what lands in WordPress and what must keep working on the day of cutover.
How we scope
- Inventory the BigCommerce catalog, variants, categories, custom fields, customers and installed apps before any work begins.
- Map each BigCommerce app to a WooCommerce plugin, a custom build or a documented decision to drop it.
- Agree in writing the URL structure, redirect rules and SEO checks that must hold after cutover.
- Confirm the target hosting, PHP and MySQL or MariaDB versions, and the WordPress and WooCommerce release lines to be used.
How we build
- Script catalog extraction through the BigCommerce Catalog API within your plan's rate limits, with logged, resumable batches.
- Import products, variants, categories and customers into WooCommerce through the wc/v3 REST API, then reconcile record counts.
- Configure High-Performance Order Storage and test the order data model before go-live, so reporting and plugins behave as expected.
- Test checkout, tax, shipping, payment gateways and redirects in a staging environment that mirrors the production hosting.
How we hand over
- Deliver the migration runbook, field mapping document, redirect table and test results as written records.
- Document the hosting configuration, backup schedule, update procedure and plugin inventory for your own staff.
- Run a supervised cutover with a rollback plan and keep the BigCommerce store live until images and data are verified.
- Train the administrators who will own WordPress, WooCommerce updates and day-to-day store operations.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the store goes live.
- Review WordPress, WooCommerce and PHP release notes so updates are scheduled and tested before they reach production.
- Retest security controls, plugin changes and payment flows after each significant update or extension change.
- Confirm with DeployOpen the support terms, response expectations and retainer scope in the written agreement before work starts.
