Intranet
Strategy & decisions

Strategic Posture: Are We Replicating Upbeat?

The question was asked directly (2026-07-08) and deserves a standing answer, because every entity in the bridge map will re-ask it. Companion to: upbeat-data-bridge-map.md, platform-opportunities.md (O3, O6), platform-readiness-scorecard.md

The answer

We are replicating Upbeat's coverage, not Upbeat — and the line between those two is a per-client choice we control, not an architectural fact.

For migrated and native clients, the suite simply is the AMS: same category as Upbeat, doing Upbeat's job with nothing behind it. This was forced, not chosen — hub-and-spoke requires the hub to model every mirrored entity (you cannot mirror contacts without a contacts model), and the marginal step from "mirror" to "master" is small. Building the bridge required building the boat.

The three deliberate differences (why this is not a clone)

  1. Different category of product. Upbeat is a per-client Dynamics 365 implementation: staff back-office, closed, no developer surface. The suite is a multi-tenant, API-first platform — scoped keys, webhooks, workflows, custom objects, widgets, MCP. We are building what a Dynamics implementation structurally cannot be; nobody hands a client developer a key to Dynamics.
  2. We do not replicate Upbeat's model. Drivers normalise at the edge (NormalizedContact, field maps); the suite models each domain its own way and translates at the boundary. The audits documented why (invoice→auto-registration entanglement, price-group sprawl): importing Upbeat's schema would be the mistake, and we are not making it.
  3. Coexistence is go-to-market posture, not limitation. Per the product vision ("system of engagement layered on whatever CRM the client already uses"): clients with a Dynamics investment get the bridge; everyone else gets the suite as system of record. Same platform, two sales motions (bridge map §6).

The two standing risks this posture must manage

R1 · Scope gravity — the operating rule

Every bridged entity invites "let staff edit this in Agend too." The expensive part of Upbeat is its authoring surfaces (events audit finding: authoring is 100% Dynamics-side), and the bridge map is — read uncharitably — a 14-row temptation list to rebuild them all.

Rule: an Upbeat-mastered entity's authoring surface is replicated only when a decision memo flips that entity to Agend-mastered (sync → migrate/native). Never by drift. The census + decision-framework pattern established for events (events-sync-vs-migrate-workflow-audit.md) is the template for any future flip.

R2 · The Upbeat relationship — OPEN, needs a deliberate position

Is Upbeat a partner whose clients we enrich, or an incumbent we are building the successor to? The architecture supports either, and the ambiguity is currently a strength: "we make your Dynamics investment better" and "you no longer need Dynamics" are both true, per client. But the first bridged client to ask "why are we paying for both?" forces the answer — and AHRI may ask it at the workshop.

Owner: Glen. Needed: an internal position (even one paragraph) before the AHRI operating-model workshop. The position governs: how the bridge is priced, whether migration is ever offered to bridged clients or only responded to, and what is said in the room when the question comes.

The one-line version

We are building the platform that makes Upbeat optional: replicating its domain because the bridge demanded it, exceeding it where a platform can, coexisting with it where the commercial relationship says to. A succession strategy with a coexistence mode — unmanaged only if we pretend otherwise.