Wikibase Cloud -> Self-Host Migration Checklist

Status: Active operational playbook (Cloud now, self-host later).

Purpose: keep hosting costs low now with Wikibase Cloud while preserving a clean migration path to Docker/custom Wikibase when scale, control, or compliance needs increase.

Current state (pre-filled, non-secret)

• Deployment mode: Wikibase Cloud (cost-first starter mode)
• Cloud owner username: `Sundog358`
• Primary project owner: `@rsung`
• Canonical internal IDs: `https://lod.metamuseum.org/{type}/{ulid}`
• Service account for automation: _pending setup_
• MFA status on owner account: _verify and record_
• Last credential rotation date: _record in runbook/release notes_
• Self-host target mode (future): _TBD_ (`Docker Compose` or `Kubernetes`)

1) Cloud-first baseline (do now)

• [ ] Confirm owner account has MFA enabled.
• [ ] Rotate temporary bootstrap password after first login.
• [ ] Create a dedicated service/bot account for automation; do not automate with personal account credentials.
• [ ] Store secrets only in environment variables/secret manager; never in committed files.
• [ ] Record current Wikibase Cloud tenant URL, org owner, and backup owner in runbook.

2) Portability guardrails (must stay true at all times)

• [ ] Keep Meta Museum canonical IDs stable: `https://lod.metamuseum.org/{type}/{ulid}`.
• [ ] Treat Wikibase Q/P identifiers as mapped externals, not canonical internal IDs.
• [ ] Preserve bidirectional mapping table: internal ID <-> Wikibase entity ID.
• [ ] Require source citation + rights metadata on publishable claims.
• [ ] Keep write operations audit-logged (who, what, when, before/after references).

3) Data model and schema discipline

• [ ] Freeze a documented minimum property set for first publishing scope (object/work/agent/place/set + rights + citations).
• [ ] Track schema changes with migration notes (new property, deprecation, mapping updates).
• [ ] Define statement-reference requirements for publishable facts.
• [ ] Maintain round/fixture-linked tests for publish payload shape and reference completeness.

4) Backup and export routine (Cloud phase)

• [ ] Schedule recurring full exports (items/properties/statements/references).
• [ ] Keep at least two independent backup locations (primary + secondary).
• [ ] Record restore drill owner and cadence (for example, monthly).
• [ ] Run a restore drill at least once before any self-host cutover decision.

5) Trigger criteria for self-host activation

Move from Cloud to self-host when one or more are true:

• [ ] Cost threshold exceeded for 2 consecutive cycles.
• [ ] Required extension/feature unavailable in Cloud.
• [ ] Compliance, data residency, or network control requirement cannot be satisfied in Cloud.
• [ ] Performance/SLO needs require infra-level tuning not available in Cloud.

6) Target self-host design decision

• [ ] Choose platform: Docker Compose (starter) or Kubernetes (production scale).
• [ ] Pick database and storage sizing profile with 12-month growth buffer.
• [ ] Define auth/SSO strategy and service-account policy.
• [ ] Define observability baseline (metrics, logs, alerts, backup-monitoring).
• [ ] Define DR objectives (RPO/RTO) and test schedule.

7) Dry-run migration (no public cutover yet)

• [ ] Export from Wikibase Cloud snapshot N.
• [ ] Import into self-host staging.
• [ ] Run parity checks:
• [ ] entity counts (items/properties/statements/references)
• [ ] random sample semantic equivalence checks
• [ ] external-ID mapping integrity
• [ ] citation/reference completeness
• [ ] Run application integration tests against staging endpoint.
• [ ] Fix mapping or schema drift before production cutover planning.

8) Production cutover checklist

• [ ] Announce maintenance window and rollback window.
• [ ] Freeze writes on Cloud publication path.
• [ ] Take final export snapshot N+1 and checksum it.
• [ ] Import N+1 into self-host production.
• [ ] Reconcile counts and integrity checks.
• [ ] Switch application publish target via configuration flag.
• [ ] Run post-cutover smoke tests (read, write, references, rights, citation surfaces).
• [ ] Unfreeze writes after verification sign-off.

9) Rollback plan (must be prepared before cutover)

• [ ] Keep Cloud environment available during rollback window.
• [ ] Keep publish-target toggle reversible without code changes.
• [ ] Document exact rollback operator and decision authority.
• [ ] Rehearse rollback once in staging.

10) Post-cutover stabilization

• [ ] Monitor error rates, latency, and queue backlog for 7-14 days.
• [ ] Re-run parity audit after first full sync cycle.
• [ ] Capture lessons learned and update this checklist.
• [ ] Decide Cloud decommission timeline only after stabilization is complete.

Ownership and review cadence

• Owner: `@rsung` (or assigned platform owner)
• Review cadence: monthly during Cloud phase; weekly during migration window
• Last review date: _fill when first adopted_