Most ecommerce maintenance problems do not begin with a difficult patch. They begin with a simple question nobody can answer quickly: What versions are we actually running?

That question matters right now. The current MariaDB lifecycle record shows community support for MariaDB 10.6 ended on July 6, 2026. The MySQL lifecycle record shows MySQL 8.0 extended support ended on April 30, 2026. A store can keep processing orders after a support date passes, but every unknown dependency makes the next security update, hosting change, or compatibility issue harder to manage.

The practical fix is not a 40-page architecture document. It is a one-page version inventory that gives the owner, developer, and hosting provider the same operating picture.

What belongs in the inventory?

Start with the components that can interrupt checkout, order processing, search, integrations, or deployment:

• Commerce application: WooCommerce and WordPress, Adobe Commerce or Magento Open Source, Shopware, a custom PHP application, or another platform.
• Runtime: PHP, Node.js, Java, or another application runtime, including the version used by production and staging.
• Database: MySQL, MariaDB, PostgreSQL, or a managed database service, including its exact release line.
• Search and caching: Elasticsearch, OpenSearch, Redis, Varnish, CDN, and related services.
• Build and deployment tools: Composer, package managers, CI pipelines, container images, and hosting control panels.
• Extensions and integrations: payment gateways, tax services, shipping tools, ERP or POS connections, marketing feeds, and custom modules.

For each item, record the installed version, latest compatible version, support or end-of-life date, business owner, technical owner, source of truth, last verification date, and a link to the vendor’s lifecycle or release notes.

Build it in five practical steps

1. Capture production before discussing targets

Do not start with what an invoice, proposal, or old ticket says should be installed. Read the versions from the live hosting environment, application dashboard, command-line tools, managed-service console, and deployment configuration. Record staging separately; it often drifts from production.

2. Map the compatibility chain

A database upgrade is not an isolated switch. Your commerce platform, PHP runtime, search engine, extensions, custom code, backup tooling, and host all need to support the destination version. Add a simple compatibility note beside every proposed target: certified, vendor-supported, tested internally, or unknown.

This is also where a version inventory prevents unnecessary replatforming. If the core platform still fits the business, a focused modernization may be safer than replacing the storefront. Our guide to when not to replatform an online store explains how to separate maintenance debt from a true platform-fit problem.

3. Sort by business risk, not version number

Put each component into one of four groups:

1. Unsupported now: validate the real support contract and plan a controlled move.
2. Support ends within 90 days: assign an owner, target, test date, and maintenance window.
3. Supported but behind on patches: schedule routine updates after compatibility checks.
4. Current and supported: keep monitoring; do not create change merely to chase a version number.

Give priority to components that touch checkout, customer data, authentication, order capture, payment handoffs, and recovery. A minor admin convenience can wait. An unsupported database behind the transaction path should not.

4. Attach evidence for backup and rollback

“Backups enabled” is not enough. Link the inventory to the last successful restore test, backup retention policy, rollback procedure, database snapshot process, and person authorized to stop or reverse a deployment. For a larger change, also record how new orders, refunds, inventory updates, and webhooks will be reconciled if rollback becomes necessary.

5. Turn the sheet into a maintenance rhythm

Review the inventory monthly and after every material deployment. A 20-minute review should answer:

• Did any vendor publish a security update?
• Did a lifecycle date move inside the next two quarters?
• Did hosting, extensions, or integrations change?
• Is staging still representative of production?
• Is there a tested path back if the next change fails?

What to fix first this week

If you operate an ecommerce site, begin with a fast owner-level check:

1. Ask your host or technical partner for the exact production versions of the application, runtime, database, search service, and Composer.
2. Confirm whether every unsupported line has an active paid support entitlement or an approved upgrade plan.
3. Choose one supported target based on platform certification, not the newest number available.
4. Verify staging, backup restoration, checkout, payment capture, order emails, search, tax, shipping, and integrations before production.
5. Assign a decision owner and maintenance window instead of leaving the work in an unowned ticket.

When a new bulletin arrives, the inventory turns “Are we affected?” from a research project into a quick lookup. It also makes a focused patch plan easier to execute; see our recent Adobe Commerce patch-planning example for the same test-first, rollback-ready approach.

Keep Phase 1 small and useful

You do not need perfect documentation before reducing risk. Phase 1 can be a shared sheet with ten to twenty critical components, verified versions, support dates, owners, and the next action. That is enough to expose the biggest unknowns and plan the first safe maintenance window.

Nexus Box helps businesses build that operating picture, validate platform compatibility, and sequence ecommerce maintenance without turning every lifecycle deadline into a replatforming project. The goal is a store that keeps working while the technology underneath it stays supportable.