An ecommerce maintenance agreement can say “managed,” “supported,” or “fully maintained” while leaving the most important questions unanswered. Which software lines are actually supported? Who receives security notices? Which patch channel is available? Who tests the change, and who can approve downtime?

Those details matter because support status is changing underneath many production stores. The current lifecycle records show that MariaDB 10.6 reached community end of life on July 6, 2026, while some enterprise support may continue through a separate paid channel. MySQL 8.0 reached end of life on April 30, 2026. Elasticsearch 7 and Composer 2.9 are also past their listed support dates.

A store may continue taking orders after one of those dates. The operational risk is that “support” on an invoice may no longer include a vendor patch, a compatible destination version, or a tested path forward. A short support audit turns that ambiguity into a practical maintenance plan.

Start with the support promise

Collect the current hosting agreement, software subscriptions, platform support contract, development retainer, and any managed-service descriptions. For each one, highlight the exact responsibility being promised.

• Does the provider patch the operating system, database, PHP runtime, search engine, commerce application, extensions, or only the hosting control panel?
• Are security updates included, or billed as projects?
• Does “monitoring” mean uptime only, or does it include failed jobs, checkout errors, search failures, and integration queues?
• Are staging tests, backups, restore tests, and rollback work included?
• Is after-hours deployment or emergency response covered?

Do not assume one vendor owns the whole stack. A host may cover infrastructure but not WooCommerce extensions. An Adobe Commerce partner may maintain application code but not a separately managed Elasticsearch cluster. A SaaS connector may support its service while leaving your custom integration outside its scope.

Match every component to a real patch channel

Support is useful only if it leads to an update your team can obtain and deploy. For every critical component, record four things:

• Installed line: the production version, not the version shown on an old proposal.
• Support source: community releases, an enterprise repository, a hosting provider, or a platform vendor.
• Entitlement: the account, subscription, or contract that provides access to fixes.
• Technical owner: the person or company responsible for evaluating and applying them.

This distinction is especially important for MariaDB 10.6. A lifecycle page may show extended enterprise coverage after community maintenance ends, but that does not automatically protect a community installation. Confirm that your organization has the qualifying agreement, uses the correct repository, and knows who opens a support case. If not, treat the installation as unsupported and plan a compatible upgrade.

Ask for evidence, not reassurance

“We keep everything updated” is not evidence. Request a compact maintenance record that can answer these questions without a week of email:

• When was each production component last checked against its lifecycle source?
• Which security or maintenance release was last installed?
• Where is the staging result or test checklist?
• When was the last backup restored successfully?
• What is the rollback point, and who can authorize using it?
• What unresolved compatibility issue is blocking the next supported target?

If the version information itself is scattered, begin with our guide to building an ecommerce version inventory. Then connect each future deployment to a simple website maintenance log so the business can see what changed and how it was verified.

Check the compatibility chain before choosing a target

The newest supported database or search release is not automatically the correct next step. Your commerce platform, PHP runtime, payment modules, extensions, custom integrations, backup tools, and hosting environment must support the same destination.

Create a one-page compatibility matrix. Put the proposed target versions across the top and the business-critical dependencies down the side. Mark each intersection as vendor-certified, tested in staging, unsupported, or unknown. “Unknown” is a research task, not an approval to deploy.

This is where a small Phase 1 is valuable. You do not need to modernize everything at once. First identify the unsupported component closest to checkout, customer data, order processing, search, or deployment. Then validate one supportable destination and the dependencies required to reach it.

Run this 30-minute owner audit

1. Ask your host or developer for the production versions of the commerce platform, PHP, database, search engine, and Composer.
2. Ask which contract or repository supplies patches for each component.
3. Name one technical owner and one business approver for every required upgrade.
4. Request the date and result of the last restore test.
5. Choose the highest-risk unsupported item and assign a compatibility check with a due date.

If a provider cannot answer these questions, the first task is not necessarily a replatform. It is to establish ownership, evidence, and a supported destination. That usually produces a faster, lower-risk first phase than starting with a broad rebuild.

Make support operational

A good support arrangement connects lifecycle notices to a named owner, a valid patch channel, staging evidence, a tested backup, and an approved maintenance window. That is what turns “supported” from a contract label into a working business control.

Nexus Box helps ecommerce teams audit that chain, validate compatibility, and plan focused upgrades for WooCommerce, Adobe Commerce, Magento, Shopware, and custom platforms. The goal is straightforward: keep the store supportable without creating unnecessary operational burden.