Migration plan — current Guild infrastructure to proposed scale stack¶

Status: Draft, pre-formation. Engineering plan only; subject to board approval, legal review of data-handling, and a privacy notice published before any member data moves.

This document describes how the existing Guild-aligned digital footprint — built around a WordPress site on Cloudways with YOOtheme, a Klaviyo email program, and a Stripe-direct payment posture — can be migrated to a more durable, audited stack suitable for a 501©(6) trade association with member-of-record obligations.

Current state (as of the proposal)¶

Layer	System	Notes
Web hosting	Cloudways (managed cloud)	Reliable, but operated under the administrator's account — needs to move to a Guild-owned account post-formation
CMS	WordPress + YOOtheme builder	Editor-friendly, established
Email & marketing automation	Klaviyo	Strong segmentation; opt-in lists from prior Guild outreach
Payments	Stripe (direct)	Ready for dues + sponsorship invoicing
App hosting (planned)	Render	Targeted for custom Node/Postgres services
Source control	GitHub (org and personal)	This proposal repo lives here
Project mgmt	Asana	Currently administrator's workspace
Files	Google Drive	Currently administrator's personal Workspace
Domains	Existing Ganjier-related domains	Owned in administrator name; need transfer plan

What works¶

WordPress + YOOtheme is a sustainable CMS for a marketing site and lightweight member portal
Klaviyo is among the strongest tools available for segmented member communications
Stripe is the right payments backbone

What needs to change before launch¶

Account ownership: every system must be owned by the Guild legal entity, not an individual
Member data of record (the legal list of who is or isn't a member) must live in a system that the Guild controls and can audit
Payments and tax records must be auditable for Form 990
Domain control must transfer with appropriate registrar lock and DNSSEC
A privacy notice and data-processing addenda must exist before member PII moves between vendors

Target architecture (post-formation)¶

                 ┌──────────────────────────┐
                 │  WordPress (marketing)   │
                 │  YOOtheme + caching      │
                 │  Cloudways (Guild acct)  │
                 └─────────────┬────────────┘
                               │ HTTPS (read-only forms)
                               ▼
       ┌───────────────────────────────────────────┐
       │  Membership service (Node/TypeScript on   │
       │  Render) — system of record for members   │
       │  Postgres (managed, daily PITR backups)   │
       └───────┬─────────────────────────┬─────────┘
               │ webhooks                │ events
               ▼                         ▼
        ┌────────────────┐        ┌─────────────────┐
        │ Stripe Billing │        │ Klaviyo (CRM &  │
        │ (subscriptions │        │ marketing automa│
        │ + invoices)    │        │ tion)           │
        └────────────────┘        └─────────────────┘
               │                         │
               ▼                         ▼
         990 + audit                Member email,
         reporting                  receipts, lifecycle

Identity and access:

Google Workspace for staff and board email under a @ganjierguild.com (or chosen) domain
GitHub Org for code, this proposal repo, and PDF distribution
Asana workspace owned by the Guild
Google Drive shared drives owned by the Guild, structured by function

Observability and security:

Centralized logging from Render, Stripe, Klaviyo, and WordPress to a single observability tool
1Password Teams (or equivalent) for shared secrets
MFA enforced on every system; SSO where supported

Data system of record¶

Today, "member or not" is implicit in WooCommerce orders or Klaviyo lists. That is acceptable for marketing but not acceptable for a 501©(6) with bylaws that grant rights to "members in good standing."

The migration introduces an explicit Membership service:

One row per person, one row per organization, with an explicit linkage table
Fields: tier, dues period start/end, payment status, COI signed?, ethics acknowledged?, voting eligibility, credential history
Source of truth for board ballots, dues notices, §6033(e) lobbying allocation, and Form 990 schedules

Stripe carries billing; the Membership service carries entitlement.

Migration phases¶

Phase 0 — Pre-formation (now)¶

Inventory every account, domain, and credential (administrator)
Confirm export paths from each vendor (Klaviyo, Stripe, WP/Woo, Cloudways, Asana, Drive)
Write a privacy notice draft suitable for member data
File migration plan with proposal repo (this document)

Exit criteria: the inventory and the export-path confirmations exist as a private document that counsel can review.

Phase 1 — Formation week (T+0 to T+7)¶

Form Guild legal entity per Issue #1
Open Guild bank account, EIN
Stand up Google Workspace under the Guild domain
Create Guild GitHub org; transfer this repo from ginalyncox to ganjier-guild
Create Guild Stripe account in the Guild's name; do not migrate payment methods yet
Adopt board policies including document retention and conflict of interest

Exit criteria: The Guild legally and operationally exists. Vendor accounts owned by the Guild exist in parallel with administrator's accounts.

Phase 2 — Member portal (T+7 to T+45)¶

Stand up the Membership service on Render with managed Postgres
Define the data model and run schema migrations
Connect Stripe Billing in test mode; build Stripe webhook handler for subscription events
Build minimal admin UI for staff and board roster
Connect to Klaviyo via API for transactional and lifecycle email
Soft-launch with founding board and a small group of charter members for live testing
Publish privacy notice and member terms

Exit criteria: A founding member can sign up, pay dues, receive a receipt, appear in the directory, and be exported to Form 990 working papers.

Phase 3 — Marketing site cutover (T+45 to T+75)¶

Move the WordPress site from administrator's Cloudways account to the Guild's Cloudways account (clone-and-cutover, not transfer-in-place, to preserve old environment as backup)
Update domain DNS to point to the Guild's Cloudways instance
Embed sign-up and renewal forms on WordPress that POST to the Membership service
Migrate any existing Klaviyo lists to the Guild's Klaviyo account, with explicit re-consent for any list older than 12 months or where consent provenance is uncertain
Migrate Asana workspace and Google Drive content into the Guild's Workspace tenant

Exit criteria: Public site, member portal, marketing automation, and project management all live in Guild-owned tenants. Old administrator-owned tenants are read-only.

Phase 4 — Decommission and audit (T+75 to T+120)¶

Reconcile Stripe activity in the old account (if any) into the Guild's books
Close or fully convert old vendor tenants
Engage the audit/financial-review firm and provide them clean, single-tenant data
Conduct a backup-restore test on Postgres
Document everything in an Architecture Decision Record under decisions/

Exit criteria: A clean 30-day month-end close is produced from Guild-owned systems, reviewed by Treasurer and audit committee.

Risks and mitigations¶

Risk	Mitigation
Klaviyo list consent provenance is unclear after migration	Re-permission lists older than 12 months; honor any prior unsubscribe; segment opt-in evidence at import
Stripe payment-method migration causes failed renewals	Use Stripe's PaymentMethod portability between accounts only with member consent; default to inviting members to re-authorize on first renewal in the new account
Domain transfer takes longer than DNS cutover	Keep registrar accounts independent of hosting; pre-stage TTLs to short values 72 hours before any cutover
Administrator's personal accounts retain access to Guild data	Run a credential rotation on day 1 of Phase 1 and document with the audit committee
Member PII committed to either repository	This repository is for proposal documents only. Member-data flows are documented here but never stored here. Reinforced in SECURITY.md
Service outage during cutover	All cutovers staged on a Tuesday or Wednesday; rollback plan documented for each phase; no cutover during dues-renewal peaks

Backup and retention¶

Postgres point-in-time recovery for 14 days, plus weekly logical dumps to encrypted object storage retained for 1 year
WordPress full backups daily for 30 days, weekly for 12 weeks, monthly for 12 months
Email archives retained per document retention policy
Financial records retained for at least 7 years

Acceptance and change control¶

Each phase exits only when its exit criteria are signed off by the Treasurer and the IT lead, and recorded in a one-page memo to the board
Material changes to the architecture (new vendors, new data flows touching PII, payment-processor changes) require a board ADR before implementation
Vendor contracts above the Treasurer's signing limit require board approval per the bylaws