Admin Dashboard Cloudflare Migration¶
Replace Adventive's legacy internal admin dashboard with an API-first architecture: a Cloudflare Workers backend API and a separately-deployed presentation layer aligned with current Adventive brand guidelines.
Status¶
- Owner: Jeffrey Lambert
- Status: Planning
- Started: 2026-04-23
- Target: TBD (define after architecture assessment)
- Repository (current):
~/Repositories/BitBucket/adventive-admin - Repository (new):
adventive/adventive-admin-api+adventive/adventive-admin-ui(proposed, not yet created)
What this project delivers¶
A full planning artifact set in the standard Adventive Engineering format, followed by implementation handoff to Claude Code (matching the Public API migration pattern).
Functional scope of the target system: - Customer service-level management (existing admin responsibility) - Billing operations UI — scope negotiated with the Stripe Billing Transition project (this project's sibling) - Operator workflows currently served by the legacy admin
Architectural scope: - Clean separation of API (Cloudflare Worker, TypeScript/Hono) from presentation (static SPA or Workers-rendered — decided in 01-architecture-assessment) - Brand-guideline-aligned UI refresh (not a cosmetic reskin of the legacy layout) - Auth/authz model appropriate for internal operator tooling
What's in this folder¶
| File / Folder | Purpose |
|---|---|
00-context.md |
Executive summary and problem statement |
01-architecture-assessment.md |
Current legacy admin audit + serverless target architecture |
02-code-updates.md |
Migration/rewrite plan: API surface, UI stack, data contracts |
03-deployment-management.md |
How the two services ship and stay shipped |
04-runbook.md |
Operational procedures for the new admin |
05-appendix.md |
References, inputs, decisions, open questions |
Adventive_Admin_Dashboard_Migration_Plan.pdf |
Final deliverable (WeasyPrint, house style) |
code/ |
Scaffold + reference implementations (actual code lives in its own repo) |
inputs/ |
Legacy admin screenshots, route inventory, brand guidelines PDF, feature list |
decisions/ |
ADR files: YYYY-MM-DD-title.md |
Serverless viability summary¶
The admin's API layer is a strong fit for Cloudflare Workers. All 14 controllers are stateless request-handlers with no persistent process state; no operation exceeds Workers' CPU time or memory limits; the largest models (Account_model.php at 1,321 lines, Report_model.php at 5,333 lines) are pure SQL wrappers that port cleanly to typed query functions behind Hyperdrive. The one exception is Report_model.php — 24 bespoke partner SQL report functions that represent the most complex single file in the codebase; these are deferred to a dedicated analytics Worker in Phase 4 rather than ported to admin-api inline. The presentation layer is a clean Cloudflare Pages SPA deployment: no server-side rendering is required, and the existing PHP views are pure data-presentation with no business logic that must move to the UI. Incremental monthly cost for the two new services (Worker + Pages) is estimated at under $6/month on the existing Workers Paid plan.
Dependencies and adjacencies¶
- Sibling project:
../Stripe Billing Transition/— billing functionality currently lives in this admin. Decisions made there will shrink or reshape the billing surface area of the new admin. - Upstream pattern:
../Public API Cloudflare Migration/— auth model, deployment pipeline, observability approach should mirror this project where sensible. - Shared infrastructure:
../Cloudflare Tunnel/— if the new admin terminates behind Cloudflare Access/Tunnel for operator auth.
Quick links¶
- Final PDF:
./Adventive_Admin_Dashboard_Migration_Plan.pdf(not yet generated) - Current-state repo:
~/Repositories/BitBucket/adventive-admin - Target platform docs: https://developers.cloudflare.com/workers/ · https://developers.cloudflare.com/pages/