Bamford × Daylesford — Technical Divergence Audit

1Executive summary

The two platforms are substantially more aligned than the February feasibility notes assumed. Since then, both sites have completed Hyvä frontend migrations and now share the same Magento version, hosting stack, checkout framework, payment provider and search/marketing vendors. The genuine divergence is concentrated in one place: the delivery & fulfilment domain (Daylesford's date-based fresh-food delivery machinery vs Bamford's flat-rate carriers) plus a long tail of brand-specific features. A working cross-site cart transfer module is already installed and enabled on both sites. This report follows the audit structure proposed and approved on DFD-749 (64-hour audit & discovery scope, approved 21 May 2026): inventory → functional mapping → cross-comparison → divergence & risk → decision register → recommended route.

2Audit scope, assumptions & methodology

Per the approved audit plan: what this audit covers, what it deliberately does not, and how the analysis was produced.

3Platform baseline

Everything below the application code is effectively the same platform. The three mismatches (Redis version, RabbitMQ, patch sets) are routine alignment work.

Themes on disk

4Module registry (app/etc/config.php)

Every module registered on each site, core and third-party. 646 modules are common; Daylesford carries 187 extra registrations (dominated by Magestore POS, Magefan blog, Yotpo, GDPR and events tooling) against Bamford's 74 (subscriptions, club, Magezon page builder, shop-by-brand, pickup).

Same module, different switch (5)

Daylesford-only registrations by vendor (187)

struck-through = registered but disabled

Bamford-only registrations by vendor (74)

5Composer packages

Of 946 packages across both lock files, 796 are identical versions. The 53 skews are mostly patch-level housekeeping; the ones worth planning around are the majors below.

All 53 version skews

Daylesford-only packages (77)

Bamford-only packages (20)

6Custom code (app/code) & wider technical inventory

This is where consolidation effort actually lives. 226 distinct modules exist across the two sites; only 27 carry the same name on both. Headline LOC figures need context: most of Daylesford's bulk is the vendored Magestore POS suite, not bespoke build.

Beyond modules: the wider technical inventory

Counts across each site's app/code (composer-delivered extensions excluded; Daylesford's totals include the Magestore estate). These are the mechanisms that share one application stack after consolidation — the reason a merge is a structured alignment exercise, not a file copy: Magento loads a single DI configuration, plugin chain, event bus, cron schedule and database schema for all websites on an instance.

Custom LOC by vendor

The 27 shared modules — how far have they drifted?

File-level comparison of same-named modules. Drift bar: green = identical files, amber = same file changed, site colours = files present on one side only. The Xtento rows are version skew of a commercial suite (an update reconciles them); the Develo rows are genuine fork drift to reconcile by hand.

7Functional capability map

Every enabled non-core module on each site — 376 distinct modules — classified into business capability areas on evidence, not name-matching. All 376 classifications are high-confidence: purposes verified by direct code reading of the bespoke modules, composer package descriptions (376 of 376), and documented commercial product function for vendor packages. The interim 45-module spot-check list was closed out on 10 Jul by reading each flagged app/code module and verifying each commercial package individually. Per-site deliverables: functional-map-daylesford.csv · functional-map-bamford.csv. Expand any area for per-module purposes.

8Delivery & checkout — the real divergence

Zoe's notes called this the reason two instances exist, and the code confirms it. The two sites model fulfilment in fundamentally different ways; almost everything else is shared vendors at drifted versions.

9Integration map

Vendor stacks are largely the same brands on both sites — the divergence is in the long tail of brand-specific services. Items in bold carry commercial/contractual weight in a consolidation.

Enablement verified against each site's app/etc/config.php, not just composer presence.

10Already in the toolbox: Develo_CartTransfer

Both sites already run a Develo-built cross-site cart handoff (Daylesford via develo/magento2-module-basket-transfer v1.2.0; Bamford in app/code; enabled on both). It was built for moving a basket between two separate Magento websites — exactly the interim-option territory Rebecca & Ian discussed.

Also relevant: Bamford's Develo_WebsiteSwitcher already preserves context when customers move between websites within one instance — a pattern that maps directly onto the post-consolidation multi-website world.

11Consolidation effort matrix

Repo-evidence ratings of what single-instance consolidation would take, per domain, on the agreed complexity scale (Low = same or near-identical · Medium = similar but needs adjustment · High = materially different custom logic · Very High = deep checkout/shipping/order/integration divergence).

12Consolidation decision register & risk register

Decision points, not solutions: what later solution design must resolve, with the audit's probable direction and where client input is required. Risks carry likelihood, impact and the mitigating next action.

Decision register

Risk register

13The three routes & recommended next phase

The three routes as tabled to the client on DFD-749 (25 Feb), now read against the audit evidence.

14Coverage against the approved audit plan

The 64-hour audit & discovery scope was approved on 21 May 2026. Mapping of each quoted task to this report. All quoted tasks are now delivered; the report is ready for playback.