PADI's digital commerce estate today is spread across distinct surfaces, each running on its own technology stack, with limited architectural consistency between them. The B2C store runs on a commerce platform with a proprietary rendering layer that sits outside PADI's emerging design system. And the B2B storefronts, serving dive professionals and retail partners across three global regions, run on a legacy cart system that is natively tied to an ERP that is being retired.

Two further member-facing surfaces — the Club Portal and the Pro Portal — sit alongside the B2C and B2B estate. Club currently runs on Vue.js with no design direction consistent with the modernized padi.com system; Pro's portal modernization has likewise been on the table but paused. Both were originally in scope for this engagement's broader vision, then placed on hold. Club has since been re-added as an optional line item based on recent developments (see Section 3, Section 4.4, Section 6); Pro remains on hold and out of scope.

Alongside this engagement, PADI's product team is running its own discovery into Unified Cart and Unified Payments — a single cart experience across devices, sessions, and geographies (anonymous and authenticated), and a platform-agnostic approach to payments across B2C and B2B. This work is still early: current-state cart mapping across business units, channels, and markets is in progress, feasibility analysis is ongoing, and it has been explicitly confirmed as not a November 2026 deliverable. We treat it as a parallel effort to track, not a requirement already defined for this proposal — see Section 3 and Open Decision D12 for how we plan to pick it up during discovery.

Through our discovery process, we identified that PADI's modernization challenge is not simply a technology refresh. It is a programme with hard external dependencies — most significantly, the retirement of the Macola ERP for North America in Q1 2027 and its replacement with NetSuite. The B2B commerce platform (Birddog) is natively connected to Macola and has no integration path to NetSuite. This means the B2B replatform is not a strategic choice but an operational necessity: without it, PADI's B2B commerce capability becomes non-functional at the point of ERP cutover.

Alongside the ERP-driven B2B dependency, PADI is executing a broader padi.com modernization programme — moving the main website and its associated properties onto a unified React/Next.js decoupled architecture with a shared design system in Nov 2026. This engagement aligns directly with that programme: the B2C and B2B stores' frontend modernization is explicitly positioned as an extension of the padi.com modernization effort, adopting its architecture, design system, and component library rather than building independent frontend solutions.

The pattern that emerges from these pain points is consistent: PADI is operating a commerce estate where data does not flow automatically between systems, where staff is absorbing operational overhead that should be handled by platform automation, and where the frontend architecture is fragmented across technologies that do not share a common design language or component model. This programme addresses all of these dimensions — not by replacing what works, but by modernizing the layers and connecting the systems that need to communicate.

1. Unify the front-end architecture — starting with B2C. Bring the B2C Store into the unified React/Next.js decoupled architecture of padi.com — sharing the modernized padi.com design system and component library, and eliminating the Frontastic silo. For B2B, Phase 1 (Americas + Canada, EMEA, APAC) is expected to launch on BigCommerce's own native frontend and available modules, not the decoupled/headless architecture — that unification is a Phase 2 possibility, once B2C's patterns are established. This B2B approach, and everything downstream of it, is subject to BigCommerce being confirmed as the B2B platform by PADI's Technology team (Open Decision D1).
2. Make NetSuite the single source of truth across B2B and B2C. NetSuite is the authoritative system for catalog, pricing, accounts, and order management across both B2B and B2C commerce. Product and pricing data flows from NetSuite into both commerce platforms via ERP-push. Orders placed on either platform are confirmed and legally invoiced in NetSuite.
3. Replace Birddog with BigCommerce, a modern, natively connected B2B platform. BigCommerce connects to NetSuite (via the Patchworks iPaaS layer), Stripe, and Avalara across three regional storefronts. Eliminate manual catalog sync and reduce the operational overhead of staff-assisted ordering — while preserving the admin-assisted ordering workflow that remains a valid B2B operational pattern for PADI.
4. Deliver scalably across regions. B2B runs as independently configurable storefronts — Americas (including Canada, now confirmed in Tranche 1 on the same NetSuite instance), EMEA, and APAC — each with a regional catalog, currency, and payment configuration. The architecture must scale to future additional storefronts (e.g. Japan) without a rebuild.
5. Reuse the padi.com customer-journey research and design system, rather than duplicating it. The padi.com modernization programme researched and designed PADI's end-to-end customer journey. B2C Store inherits that research and component library directly — it is the same journey extended into the commerce layer, not a separate audience requiring its own discovery. B2B Phase 1 applies the same design system as a lightweight branding pass on top of BigCommerce's own built-in frontend — see Section 4.3.1 and Section 4.4.5 for what that means in practice. The optional Club Portal, if confirmed, differs: it moves onto the same padi.com decoupled architecture as B2C Store, not a branding pass on its current frontend — see Section 6.

The padi.com modernization workstream, targeted for November 2026, researched and designed PADI's end-to-end customer journey, including the browse-to-checkout path. Per the alignments we have had with PADI team so far, that research is treated as the single customer journey the commerce layer extends, not a separate audience needing its own discovery: the B2C Store inherits it directly, with no fresh foundational research run for the storefront itself.

For B2B Phase 1 (Americas + Canada, EMEA, APAC), the same principle applies in a lighter form: BigCommerce's own native B2B storefront is the starting point, with PADI branding and the shared design tokens applied as a theming pass, not a ground-up rebuild. No dedicated card sorting, user flow diagrams, or user research are scoped for this phase; headless architecture and the deeper, surface-specific design investment it would justify are deferred to a Phase 2 evaluation, once B2C's patterns are established.

The optional Club Portal, if confirmed as part of this workstream, is different in kind: rather than staying on its current frontend, Club's modernization moves it onto the same padi.com decoupled architecture built for the B2C Store, with Cloudflare routing from club.padi.com to padi.com/club to showcase the unified experience. The same no-dedicated-research approach still applies — no card sorting, UFDs, or user research scoped for Club either — but the frontend itself is rebuilt, not just rebranded. If Club isn't confirmed, none of this happens and Club remains exactly as it is today.

The result is one design system and one visual language carried consistently across every surface, sized to what each phase actually needs — a lightweight theming pass now, with room for deeper design investment later if PADI decides to pursue headless.

These five objectives are not independent — they are sequenced and interdependent. The frontend unification objective depends on the padi.com modernization programme delivering its design system and architecture. The NetSuite source-of-truth objective depends on the ERP implementation being sufficiently complete to expose the data model. The B2B platform objective — BigCommerce, selected in August 2026 — is now unblocked for build; remaining sequencing risk sits with final BigCommerce/Patchworks pricing, not the platform choice itself. Managing these dependencies is a core part of Axelerant's delivery responsibility in this engagement.

As part of the padi.com modernization Phase 1 release (November 2026), the B2C Store will be unified under padi.com via Cloudflare routing — becoming the /store URL path. This Cloudflare routing layer serves as the interim URL-unification mechanism for the B2C store portal until its modernized React/Next.js frontend is built and made live as part of the decoupled padi.com architecture. The routing remains in place through the modernized B2C store go-live on 1 February 2027. Once the B2C store's new frontend is live, the Cloudflare routing is replaced by the native decoupled architecture. B2B storefronts remain as independent subdomains and are not routed through padi.com. Existing domain redirects handle continuity for bookmarked URLs throughout.

B2B — Canada is no longer listed here: it is now confirmed in scope for B2B Americas Tranche 1 (previously Open Decision D5 — see Section 3.3, resolved). Club Portal is also no longer listed here: it is in scope as an optional track (see Section 3).

Macola ERP is the origin of product catalog data for both B2C and B2B, but this data reaches each commerce platform through manual processes rather than automated sync. The B2C store's Frontastic rendering layer does not share code, components, or design tokens with anything else in PADI's technology estate. And Birddog — the B2B cart — is natively connected to Macola only: there is no integration path to NetSuite, which means the B2B commerce surface becomes non-functional at the point of ERP cutover unless it is replaced before that date.

• Apply the inherited padi.com design system and component library directly to the store templates — PLP, PDP, cart, and the checkout shell — so the storefront reads as one continuous experience with the rest of padi.com.
• No dedicated user research, card sorting, or UFDs are scoped for this track — the store inherits the diver segment, IA, and customer-journey work already completed on padi.com.
• DAM-driven product-asset presentation to enrich the PDP and merchandising without touching the catalog or commerce engine.
• Lo-fi wireframes → hi-fi UI mockups applying the shared component library to the store's existing screens — a theming and layout pass, not new UX design.

Deeper conversion-focused UX work (funnel analysis, A/B and usability testing) is out of scope for this workstream — consistent with the CRO exclusion in Section 3.2 — and can be considered as a future change request once the new frontend is live and stable.

Option A — CommerceTools

Not the leaning choice at this stage, though not officially ruled out. CommerceTools has no native B2B cart — a B2B module would need to be built on top of the existing CT B2C foundation — and no native NetSuite connector, so an iPaaS or custom connector is needed either way. Two sub-options were evaluated; pricing for both was sized during discovery but is not carried forward in this proposal, since the evaluation currently leans toward BigCommerce (see Section 6):

• A1 — CommerceTools + iPaaS. Lower upfront build cost; iPaaS connector maintained by vendor; faster to implement. Trade-off: no native B2B cart on CT; iPaaS batch sync rather than real-time; recurring iPaaS license.
• A2 — CommerceTools + custom connector. Real-time bidirectional sync; Axelerant owns and maintains the connector. Trade-off: no native B2B cart; higher upfront build cost; requires confirmed NetSuite data model access before build begins.

Option B — BigCommerce (leaning choice, pending final decision)

Out-of-the-box B2B storefront with a lower custom-dev burden overall — currently the direction the evaluation is leaning toward. The native B2B Edition reduces storefront build effort significantly, a deliberate trade-off against the unified design system/headless direction that would be accepted for Phase 1 to protect the Feb 2027 ERP deadline, if confirmed. B1 and B2 were evaluated for context, but given the leaning choice is BigCommerce + Patchworks based on recent developments, only the Patchworks integration approach is being sized going forward — we'll revisit B1/B2 if the final evaluation and direction changes:

• B1 — BigCommerce + available native NetSuite connector. Out-of-the-box B2B storefront; lower custom-dev burden overall. Trade-off: native connector possibly mono-directional; may need custom work for bidirectional ERP-push.
• B2 — BigCommerce + custom connector. Out-of-the-box B2B storefront; real-time bidirectional sync; Axelerant builds and maintains the connector. Trade-off: higher upfront build cost for the custom connector.
• Patchworks iPaaS (under evaluation, pending final decision). A pre-built BigCommerce + NetSuite blueprint that would close the bidirectional-sync gap B1 leaves open, without the full custom-build cost of B2 — structurally between the two. Not yet finalized; final commercials pending PADI's order-volume data to BigCommerce and Patchworks (Open Decision D7).

Option C — NetSuite SuiteCommerce

Native to the ERP, with no sync layer needed — but not headless, which conflicts with PADI's longer-term member-experience and unified-cart direction. The least likely of the three options based on the evaluation so far, though not formally closed out pending PADI's Technology team's final decision. Not sized.

The Patchworks integration approach is the one being sized going forward, given the leaning choice — B1 and B2's original figures are retained in Section 6 purely as the bounding range for that estimate, not as separately priced alternatives. A1 and A2 (CommerceTools) were also sized during discovery, but that pricing isn't carried forward — see the summary above for what each involved. All figures predate PADI's final decision and will be revisited if the direction changes.

• Apply PADI branding (logo, colour, typography) and the shared design tokens to BigCommerce's native B2B storefront templates — a theming pass on the existing platform UI, not a rebuild.
• No dedicated B2B segments/scenarios research, card sorting, or UFDs are scoped for this phase.
• Account-level pricing, bulk ordering, reorder, and staff-assisted admin ordering are delivered using BigCommerce's native B2B capabilities as-is, styled to PADI's branding rather than custom-designed.
• EMEA and APAC (Tranche 2) reuse whatever theming and configuration is established for B2B Americas — fresh work is limited to regional catalog, currency, and payment configuration differences (including the Datatrans → Stripe transition for EMEA).

• Apply the inherited padi.com design system and component library directly to the Club screen set — profile, membership, benefits, renewals, transaction history — so Club reads as one continuous experience with the rest of padi.com.
• No dedicated Club-specific user segments/scenarios research, card sorting, or UFDs are scoped for this phase — the same no-dedicated-research approach applied to B2C and B2B Phase 1 (see Section 4.3.1, Section 4.4.5).
• Lo-fi wireframes → hi-fi UI mockups for the Club screen set, built directly on the shared component library — a rebuild using inherited patterns, not new research-led design.

• Full technical SEO audit (site speed, indexing, crawl depth, Core Web Vitals).
• Content audit for high-value pages, evergreen articles, and underperforming keywords.
• Updated metadata, schema markup, and improved internal linking to boost discoverability.
• Ensuring article structures are optimized for AI-driven/featured snippet visibility (AEO).
• GEO/locale-based adjustments where applicable.
• Creating SEO-ready pathways from editorial content to PADI courses and products without compromising editorial integrity.

The goal at each platform go-live is for the new React/Next.js frontend to deliver a measurably stronger technical SEO baseline than the surfaces it replaces.

This work is sequenced to three milestones: the padi.com Phase 1 release in November 2026 (Cloudflare routing for padi.com, Blogs, and Store — confirmed; Club and Pro routing and their analytics work contingent, see above), the Store redesign go-live and Mobile app go-live in February 2027, and the B2B storefront go-lives (Americas in Feb 2027, EMEA and APAC in May 2027).

4.8.1.1 PADI.com — modernization (redesign)

4.8.1.2 Blogs (blog + pros-blog) — WordPress to Drupal 11 migration into padi.com

Full platform migration — proceeds regardless of the Club/Pro routing decision.

4.8.1.3 Store — Cloudflare routing only (store.padi.com → padi.com/store)

The store's redesign and ecommerce event buildout happen at the February 2027 Tranche 1 go-live. This November phase is URL routing and tracking continuity only — confirmed, no redesign work.

4.8.1.4 Pro — Cloudflare routing only (pro.padi.com → padi.com/pro)

4.8.1.5 Club — Cloudflare routing only (club.padi.com → padi.com/club)

4.8.2.1 Store — redesign go-live (ecommerce events)

4.8.2.2 Mobile (iOS + Android) — go-live (Firebase SDK, not GTM web)

4.8.3.1 Americas — b2bamericas.padi.com (go-live Feb 2027; no analytics currently identified)

4.8.3.2 EMEA — b2bemea (go-live May 2027)

4.8.3.3 APAC — b2bapac (go-live May 2027)

Club Portal isn't in either tranche above, since it's an optional add-on (see Section 4.5, Section 6). We'll plan this during discovery and align on a go-live for Club Portal modernization once its scope is confirmed to be included.

The BigCommerce + Patchworks line consolidates what Section 4.4.1 documents as the evaluated options and sub-options — see that section for the full audit trail of what was considered and where PADI's Technology team's final platform decision (Open Decision D1) currently stands.

Priced on a ~320 dev + ~250 design hour basis (see Section 4.5). Re-added as a separate line item based on recent developments — not yet confirmed for build, and kept independent of the core programme total.