Gap Analysis & Constraints

Key Takeaways

1. CIB Seven (Camunda 7) EOL is the highest-urgency constraint — Camunda 7 CE support ended October 2025. Two BPM services (purchase-request-bpm, shoutout-bpm) and the Keycloak identity sync plugin depend on it. Replacement is mandatory regardless of other modernization decisions.
2. 11 active external API integrations are immovable — Stripe, Mux, Zoom, Stream Chat, Twilio, Mandrill, Google Calendar, Elasticsearch, LogRocket, CastAI, and Airbyte/Snowflake. API keys, webhook URLs, and external IDs must be preserved during any migration.
3. ~110 of 191 repos are archivable — 63 repos untouched since before 2025, plus ~47 Gen 1 services with confirmed Gen 2 replacements. Only ~35 application services and ~15 infrastructure repos are active.
4. Observability has critical gaps — No alerting configuration, APM disabled, no SLOs, no distributed tracing adoption, no error budget tracking. Monitoring infrastructure exists (Prometheus, Grafana, Elasticsearch) but is under-utilized.
5. Buy-vs-build analysis identifies 4 SaaS replacement candidates — Email delivery (Mandrill → SendGrid/Postmark), SMS (Twilio already SaaS — keep), BPM engine (CIB Seven → Temporal/lightweight state machine), logging pipeline (peeq-logging → Cloud Logging native).

Migration Decision Question

What are the highest-impact gaps and debts blocking modernization?

1. Immovable Constraints

These cannot be changed by the modernization effort — the architecture must accommodate them.

1.1 External API Integrations (Must Preserve)

1.2 Multi-Brand Architecture (Must Support)

• 4 production brands: The Agile Network, NIL Game Plan, VT NIL, Speed of AI
• All differentiation is config-only (H11 L2 Verified) — same Docker images, same Helm charts
• Config mechanism: values-globals.yaml per tenant (domain, Keycloak realm, API keys, feature toggles)
• Implication: Any Gen 3 architecture must support multi-tenancy. Current cluster-per-tenant model works but is expensive.

1.3 Keycloak as Universal Identity (Must Migrate Carefully)

• 28+ services validate JWT tokens against Keycloak
• All user IDs are Keycloak UUIDs — no local identity generation anywhere
• Custom SPIs: Magic Link (passwordless email/SMS) and Session Restrictor must be preserved
• CIB Seven plugin: Keycloak→Camunda identity sync — must be replaced when CIB Seven is replaced
• Implication: Keycloak must be the LAST thing migrated, or must remain backward-compatible throughout

1.4 Database-Per-Service Isolation (Must Respect)

• 35 PostgreSQL databases per tenant — no cross-database foreign keys
• All inter-service data references use Keycloak UUIDs or external IDs
• Shared DB exception: email/sms/notifications share peeq-notification-service-db
• Implication: Services CAN be migrated independently (good), but data consistency depends on messaging contracts (must not break)

1.5 Data Volume (Partially Unknown)

• Cloud SQL tier: db-custom-2-6656 (2 vCPU, 6.5 GB RAM)
• Max connections: 750 shared across 35 databases
• H8 still L0: Actual row counts and table sizes unknown — need production DB access
• Implication: Cannot estimate migration windows or decide database consolidation without actual volume data

2. Dead Code & Inactive Services Assessment

2.1 Confirmed Dead Backend Services (Archive Immediately)

Total: 12+ services confirmed dead or replaced

2.2 Frontend Dead Code

Impact: ~17% of frontend API gateway code targets non-existent production services.

2.3 Backend Dead Code

2.4 Archive Candidate Summary

3. Feature Parity Gaps

3.1 Gen 1 Features Not in Gen 2

Finding: No feature parity gaps. All Gen 1 unique features were either deprecated, replaced by SaaS (Zoom), or replaced by Gen 2 alternatives (SSE).

3.2 Missing Capabilities (Not in Gen 1 or Gen 2)

4. Coupling Hotspots

4.1 Highest-Coupling Services

4.2 Coupling-Driven Migration Constraints

1. Keycloak must be last — changing identity affects all 28+ services simultaneously
2. Inventory requires facade — 5 dependents cannot all migrate at once; need backward-compatible API during transition
3. BPM instances must drain — purchase-request-bpm and shoutout-bpm have in-flight state that cannot be cold-migrated
4. SSE is infrastructure — treat as platform service, upgrade in place rather than migrate
5. Notification pipeline is a chain — notifications → email/sms → Mandrill/Twilio. Consolidate before migrating dependents

5. Buy-vs-Build Analysis

5.1 SaaS Replacement Candidates

5.2 Services Already Using SaaS

The platform already delegates significant functionality to SaaS: - Payments: Stripe (Checkout, Elements, Billing Portal) - Video: Mux (transcoding, delivery, signed URLs) - Video conferencing: Zoom (webinars, registrations) - Chat: Stream Chat (messaging, channels) - SMS: Twilio (messaging, verification) - Email: Mandrill (transactional email) - Analytics: Airbyte + Snowflake (CDC + warehouse) - Session replay: LogRocket (frontend monitoring) - Cost optimization: CastAI (GKE node management)

Finding: The platform already follows a SaaS-delegation pattern extensively. Gen 3 should continue this pattern. The only custom infrastructure at risk is the BPM engine and logging pipeline.

6. Security Gaps

7. Compliance Gaps

8. Hypothesis Summary for Gap Analysis

Last updated: 2026-01-30 — Session 10 Review by: 2026-04-30 Staleness risk: Medium — gaps may be addressed as modernization progresses