Events: Sync vs Migrate — Client Workflow Audit

The evidence-gathering pass behind the decision framed in upbeat-data-bridge-map.md §4 and the W4 note in writeback-two-way-sync.md. Method: two parallel code audits (2026-07-07) — the legacy WP events surface (agend-pro, connector + importer + checkout, ~10k lines traced) and the native Events module (apps/events + events-api + migrations). Code answers most of it; §6 lists what only humans can. Status: EVIDENCE COMPLETE · decision pending §6 inputs

1 · Finding: event authoring is 100% Dynamics-side

WordPress contains no code path that creates or edits event substance — dates, venue, capacity, products, prices, price-point schedules, price groups, packages, CPD types, speakers, sponsors, member-only/sell-on-web flags are all deserialized from BusinessConnector and force-overwritten into Tribe Events on every sync (the one carve-out: an ACF exclusion list preserving hand-edited descriptions). The admin "Sync with Upbeat" button is a pull. The sole web-side authoring seed is create_event_request — a member-submitted proposal staff confirm in Dynamics.

Implication: association staff live in Dynamics event screens today. Migration = rebuilding that entire authoring surface and retraining staff. This is the strongest pro-SYNC fact.

2 · Finding: the web write surface is narrow (~10 endpoints)

Everything the web writes back for events: registration create (walk-ins) / update (attendee enrichment: badge, dietary, accessibility, pronouns, travel), waitlist join, event survey, event request create/update, speaker profile upsert, CPD claim — plus the invoice/payment family shared with commerce. W4's up-stroke is smaller than the write-back doc assumed. This weakens the "W4 is huge" premise on both paths.

3 · Finding: the invoice→registration entanglement (kills the naive hybrid)

Upbeat auto-creates one registration per seat when an event product line is added to an invoice. WP then waits and retries up to 10× for those registrations to appear before enriching them (checkout.php:666-760). Consequences:

The earlier hybrid sketch ("migrate event management, keep a thin financial up-stroke via W2") is not clean: if invoices keep flowing into Upbeat with event product lines, Upbeat keeps manufacturing registration records that now duplicate Agend-native ones.
A true migrate therefore means event revenue posts to Upbeat (if at all) as plain revenue lines, not event-product lines — or via a ledger export — with registrations living only in Agend.

4 · Finding: native Events is strong for simple events, structurally short for conferences

Production-grade today: atomic capacity (FOR UPDATE RPCs), time-windowed member/non-member/corporate pricing tiers, multi-attendee (≤50) + guest registration into CRM contacts/orders, check-in, waitlist with positioned reservations, per-event Xero coding, full staff admin UI + analytics, and a The Events Calendar import wizard (directly useful for migration — TEC is exactly what the legacy build populates).

Twelve gaps vs the Upbeat model; three structural: (1) no sessions/parent-child events, (2) no ticket packages, (3) no CPD linkage (module exists, no event awareness). Tail: member_only schema-only (unenforced), no badges/ticket numbers/dietary, no custom registration questions, no surveys, no event requests, speakers/sponsors have no admin UI, no recurring events, waitlist auto-promotion unverified.

5 · Finding: much of the legacy complexity is self-inflicted impedance mismatch

A large share of the "40% bespoke" burden is WP-specific, not Upbeat-specific: Tribe stock-decrement reconciliation, price re-resolution at render and cart, 10× retry races, WooCommerce product mirroring, venue GUID/country quirks. A native sync (Upbeat → Agend Events tables) would carry Upbeat's model but shed the Tribe/Woo mismatch — meaning the sync path is cheaper into Agend than it ever was into WordPress. Genuine Upbeat-model complexity that survives either path: parent/child + sell-only-packages, packages with per-audience website pricing, price-point schedules per price group, CPD types, member-only gating, group registrations.

6 · What only humans can answer (the interview + census pack)

Event-shape census (data, not opinion — run against Upbeat/legacy data first): over the last 24 months, count events by shape: % with child events; % sold via packages; % with >1 price group beyond member/non-member; % with CPD types; % member-only; % free/quick-buy. If the conference shape is <10% of volume, the structural gaps mostly price one flagship event per year, not the platform.

Staff interviews (per client, ~30 min):

Who creates events, in which Dynamics screens, how often? What else do they do in Dynamics in the same sitting (or is events their only Dynamics task)?
Walk through the last conference setup: sessions? packages? price-point schedule? How long did it take and what hurt?
Does event revenue have to post into Upbeat's ledger as event-product lines (finance/reporting dependency), or is summarised revenue acceptable? Who consumes Upbeat's event reports today?
Registration operations: who uses attendee lists, check-in, dietary reports — from Upbeat or from the website exports?
If event management moved to a purpose-built Agend screen (with training), what would you miss from Dynamics?

7 · The decision, framed by the evidence

	Path A · SYNC (build the driver)	Path B · MIGRATE (adopt native + close gaps)
Build	Events driver carrying the genuine Upbeat model (§5 survivor list) + W4 up-stroke (~10 ops, narrow per §2)	Sessions + packages + CPD linkage (3 structural builds) + gap tail as needed + one-off migration (TEC import wizard assists) + staff retraining
Staff impact	None — Dynamics workflow untouched (§1)	Full retraining out of Dynamics event screens
Financial flow	Unchanged (invoice lines → auto-registrations)	Registrations Agend-native; Upbeat gets summarised revenue or none (§3 forces this)
End-state	Two event systems forever, bridged	One event system; native module becomes the product
Strategic asymmetry	Effort serves only Upbeat-connected clients	Effort compounds for every platform client — sessions/packages/CPD make native Events sellable to associations with no Dynamics at all
Killed by	Census showing simple-event dominance + staff indifference to Dynamics	Finance requiring event-product lines in Upbeat's ledger, or staff refusal

Path C (per-shape hybrid — simple events native now, conferences stay synced) is only defensible as a transition: permanent operation of two systems is worst-of-both.

Reading of the evidence so far: §1 is the strongest sync argument and §§3+5 + the strategic asymmetry are the strongest migrate arguments. The census (§6) is the tiebreaker and costs a day. Recommendation: run the census before any interviews — if simple events dominate, Path B with the three structural builds scheduled behind the census numbers; if conference-shape dominates, Path A with the driver scoped to the §5 survivor list.

8 · Next actions

Event-shape census — query pack written and ready to run: events-shape-census.sql (same folder). Runs against any client's WP database via wp db query; every meta key verified against the importer. ~1 hour per client, unblocks everything. Note its caveats header (web-visible events only; member-only category is option-gated; multi-price-group needs an API pass).
Staff interviews per §6 (AHRI first) — schedule alongside the operating-model workshop.
Decision memo (one page, cites this audit) → updates upbeat-data-bridge-map.md row 6 and the W4 note from "under evaluation" to "decided".