How Much of the Magento Market Is Running Old Software?

Executive finding

The available evidence proves that old Magento software remains visible on thousands of live websites. It does not support a reliable count or percentage of the Magento installed base that is currently unsupported, unpatched, or insecure.

The main obstacle is version resolution. Our purchased Magento 2 export identifies Magento 2 domains but does not provide a minor or patch version. BuiltWith's public reports identify some sites at the Magento 2.0, 2.1, 2.2, 2.3, or 2.4 level, but the reports overlap and do not resolve 2.4.x patch lines. In September 2026, knowing only “Magento 2.4” is not enough to determine support status.

RN-007 should therefore tell a story about a version visibility gap, supported by direct evidence of a legacy tail. It should not publish a headline such as “X% of Magento stores are outdated” from the current data.

Research questions

1. How much of the detected Magento footprint can be assigned to a version family?
2. Which directly detected version families are clearly legacy?
3. What can a Magento 2.4 detection tell us about current support status?
4. Which counts are comparable, and which may overlap?
5. What additional evidence is required to estimate the maintenance burden for agencies?

Evidence ladder

We classify version evidence in descending order of usefulness:

An agency should not move a domain up this ladder without new evidence.

1. What the purchased exports establish

We compared two BuiltWith exports dated August 24, 2026.

The two lists are not nested. The Magento 2 export contains 2,289 domains absent from the general export. The general-only group also includes 2,491 domains with a Hyvä label, even though Hyvä is a Magento 2 and Adobe Commerce product suite.

This invalidates a tempting calculation. Neither 151,428 minus 109,428 nor the 44,289 domain-level difference can be called Magento 1.

The general export contains 1,493 OpenMage labels. OpenMage is a maintained community fork in the Magento 1 family, so it should be reported separately from unsupported original Magento 1 installations. A label does not confirm patch or maintenance status.

2. Public reports show a legacy tail

BuiltWith's public version pages reported the following live-site counts during this research on September 3, 2026:

Sources: Magento 1.5, 1.6, 1.7, 1.8, 1.9, Magento 2.0, 2.1, 2.2, 2.3, and 2.4.

Adding the Magento 1 rows gives 9,206 detections, and adding Magento 2.0–2.3 gives 7,165. These are gross version-page totals, not deduplicated domain counts. A domain can carry more than one version signal, the set does not include every possible Magento 1 version, and public reports can update at different times.

The gross sums may be used to describe the visible scale of legacy detections. They must not be divided by the general Magento total to calculate market share.

During our broader research, the Magento 1.7 public count changed between retrievals. Parent totals shown on some cached pages also differed. This reinforces the need to record retrieval time and obtain domain-level exports from one snapshot before calculating shares.

3. Magento 2.4 is not a support-status category

BuiltWith reports 33,135 live Magento 2.4 sites, but the label covers multiple release lines. As of September 3, 2026, Adobe's lifecycle page lists materially different states:

Source: Adobe Commerce software lifecycle policy.

The extended and security-only provisions described by Adobe are product- and entitlement-specific. Adobe states that the 2.4.6 extended provisions are available to Adobe Commerce customers and do not extend support for third-party dependencies. Adobe Commerce system requirements

Therefore, a 2.4.4 or 2.4.5 family signal does not alone establish the support available to a particular merchant. Edition, entitlement, exact patch, and dependencies matter. A generic 2.4 signal cannot distinguish 2.4.4 from 2.4.9 at all.

4. Patch level matters inside a supported release line

Adobe recommends installing the latest security patch available for each release. Its released-versions page shows, for example, 2.4.7-p10, 2.4.8-p5, and 2.4.6-p15 released on May 12, 2026. Adobe released versions

A store on the 2.4.7 line could therefore be inside the regular-support window while still missing later security fixes. Conversely, a merchant on an older release line may have access to a special support arrangement. Minor-version detection alone cannot resolve either case.

For agencies, the practical unit of assessment is not “Magento 2.4.” It is at least:

• Product and edition.
• Exact core package version.
• Security patch level.
• Installed extensions and their versions.
• PHP, database, search, cache, queue, and other dependencies.
• Deployment and maintenance ownership.

Public website detection generally cannot provide this complete inventory.

5. What the data can and cannot say

Supported conclusions

• Legacy Magento families remain detectable on thousands of live websites.
• Magento 1.9 is the largest directly visible Magento 1 version group in the public reports reviewed.
• BuiltWith reports more than 7,000 gross live detections across Magento 2.0–2.3 version pages.
• Magento 2.4 is the largest visible minor family, but its support status is unresolved without a narrower version.
• A large part of the purchased Magento 2 domain list has no publicly reported minor-version assignment in the evidence collected here.
• Agencies face a real version-discovery problem before they can scope maintenance work.

Unsupported conclusions

• That 44,289 general-only domains run Magento 1.
• That the gross public version counts are mutually exclusive.
• That every site with a legacy version signal is an active store.
• That every detected legacy site is unpatched or exploitable.
• That every Magento 2.4 site is current or supported.
• That the absence of a visible version means a merchant is current.
• That a CDN, WAF, or managed host compensates for an unsupported application version.

6. Recommended version-status model for agencies

RN-007 should use operational categories rather than a binary safe/unsafe label:

This model gives agencies a useful service entry point: reduce uncertainty first, then recommend maintenance or migration based on verified facts.

7. Data required for a defensible market estimate

To estimate how much of the Magento market runs old software, acquire domain-level exports for Magento 1.5–1.9 and Magento 2.0–2.4 from the same timestamp. If BuiltWith offers narrower 2.4.4–2.4.9 reports, obtain those too.

Then:

1. Normalize root domain and location-on-site separately.
2. Deduplicate redirects and identify multiple storefronts under one primary domain.
3. Preserve all version signals per domain rather than forcing one label.
4. Mark conflicting signals for review.
5. Join product/edition signals such as Magento Enterprise, Adobe Commerce B2B, OpenMage, and Hyvä.
6. Map exact version evidence to a dated lifecycle table.
7. Report known-supported, known-legacy, transitional, and unresolved groups separately.
8. Validate a stratified sample manually and, where authorized, against merchant package inventories.
9. Repeat the snapshot to measure movement rather than infer it from First Detected.

The preferred primary source for an agency client is a permission-based software inventory. For Magento Open Source, Composer files record exact package versions and dependencies. Adobe documents Composer as the package-management mechanism for current Magento Open Source releases. Magento Open Source packages

8. Suggested sampling plan

After acquiring domain-level version lists, select approximately 300 records:

• 75 direct Magento 1 family detections.
• 75 direct Magento 2.0–2.3 detections.
• 75 Magento 2.4 detections, stratified by the narrowest detectable version.
• 50 Magento detections with unresolved version.
• 25 OpenMage detections.

Stratify within these groups by traffic/spend band and region. The exact allocation can be changed after deduplication; 300 is an operational starting point, not a statistical guarantee.

For public review, record only what can be observed without authentication or intrusive requests: working storefront status, redirect behavior, version evidence, and conflicting technology signals. Do not infer patch status from a generic frontend fingerprint.

For merchant-authorized reviews, collect package and dependency versions, extension ownership, last applied update, environment separation, and release process. This is the evidence needed to turn a market signal into an agency recommendation.

9. Implication for RN-008

RN-008 should not compare “old” and “current” sites using the current general and Magento 2 exports alone. It should begin after RN-007's domain-level version dataset is available or clearly label version groups as detection-only.

Its public security-signal sample can test observable conditions such as HTTPS behavior, indexed staging environments, exposed diagnostic information, and selected response headers. Those are indicators for further review, not proof of vulnerability.

The strongest RN-008 design will compare public signals across confirmed or higher-confidence version groups while keeping unknowns separate.

Methodology and limitations

Purchased-export counts come from the local All Live Magento Sites — 2026-08-24 CSV and All Live Magento 2 Sites — 2026-08-24 ZIP previously reconciled at root-domain level. Public BuiltWith counts were retrieved on September 3, 2026 and may change continuously.

The public version counts were transcribed from individual BuiltWith usage-statistics pages. We did not purchase the corresponding version-level domain lists, so we could not deduplicate overlaps or join those counts to our local merchant attributes.

Lifecycle status is dated September 3, 2026 and based on Adobe documentation. Product edition and entitlement affect some extended-support provisions. Third-party dependency support is separate from core application support.

“Live website” is BuiltWith's report category. It does not prove that checkout works, that the site represents a unique merchant, or that the detected version is the only application on the root domain. This research assesses market visibility and evidence quality; it is not a security audit of any named merchant.