migration-ready-schema — Claude Code skill: setup and usage

---
name: migration-ready-schema
description: Data-model rules that make a schema importable from day one, so the migration-import-engineer is never blocked on missing columns. Every SMB Product-Builder product must let a customer bring their data from an incumbent (ServiceTitan/Toast/Mindbody/Shopify) — that requires provenance (source_ref) and rollback (import_batch_id) on importable entities, and modelling real-world actors as entities rather than inline fields. Applied by architect when writing the data model in ARCH-{slug}.md, and checked by migration-import-engineer. One cheap rule set prevents the migration↔architecture seam gap from recurring across all 40 products.
when_to_use: |
  Apply when:
  - architect writes the Data contracts / data model section of ARCH-{slug}.md
  - migration-import-engineer verifies the destination schema can satisfy its
    idempotency + rollback invariants
  - any new entity is added that could be populated from an import or a third-party sync
  Do NOT apply to purely ephemeral / derived tables (caches, materialized views) that are
  never imported into.
effort: low
allowed-tools: Read, Write, Grep, Glob
paths:
  - "docs/architecture/**"
  - "docs/data-import/**"
---

# Migration-ready schema — importable from day one

Every SMB product's wedge is **low switching cost** — the customer brings their data from
the incumbent. If the schema can't receive that data idempotently and reversibly, the
`migration-import-engineer` blocks and the wedge is a slogan. These rules are cheap at
design time and impossible to retrofit cleanly. **Apply them to the data model in ARCH,
before any import is designed.**

## The three rules (the ones that actually block imports)

### 1. Importable entities carry `source_ref` (provenance)
Any entity that can be populated from an incumbent export or a third-party sync gets a
nullable, **unique** `source_ref` column:

```
source_ref  text  UNIQUE NULL   -- e.g. "servicetitan:pricebook:8842"
```

- It is the **dedup key** for idempotent re-import (re-running an export never duplicates).
- Namespaced `{source}:{type}:{id}` so two incumbents can't collide.
- Nullable because natively-created rows have no source.

### 2. Importable entities carry `import_batch_id` (rollback)
```
import_batch_id  uuid  NULL  -- tags every row written by one import run
```
Rollback = delete where `import_batch_id = ?`. Without it there is no undo, and an import
with no undo is one a user will never trust enough to run.

### 3. Model real-world actors as entities, not inline fields
A customer, contact, vendor, member, or tenant is an **entity with its own table**, even if
v1 only stores a name + phone. Reason: imports populate these **before** the dependent
records (quotes, orders, bookings) exist — an inline `customer_name` field on `Quote` has
**nowhere to land** an imported customer. Inline-actor is the single most common migration
blocker.

```
-- WRONG (blocks import):  Quote(... customer_contact text)
-- RIGHT:                   CustomerContact(id, ..., source_ref, import_batch_id)
                            Quote(... customer_contact_id → CustomerContact.id)
```

## Supporting rules (cheap, prevent silent data loss)

- **Money in integer minor units** (`*_cents`), never float — incumbent exports carry exact
  amounts; floats corrupt them.
- **Timestamps carry the source timezone** (store UTC + offset, or tz-aware) — exports use
  local times; ambiguous `MM/DD` and naive datetimes lose data.
- **Infra tables for integration bookkeeping exist in the model**: `outbound_message`
  (idempotent send guard), `processed_webhook_events` (event dedup). The
  integrations-engineer relies on them; enumerate them so they aren't a surprise.

## Checklist (architect runs this before finalizing the data model)

```
For each entity in the data model:
- [ ] Can it be imported from an incumbent or third-party? If yes → has source_ref + import_batch_id
- [ ] Is it a real-world actor (customer/contact/vendor/member)? If yes → it is its own entity, not an inline field
- [ ] Money fields integer minor units? Timestamps tz-aware?
- [ ] Listed the infra tables (outbound_message, processed_webhook_events) the integrations layer needs?
```

A data model that passes this checklist hands `migration-import-engineer` a destination it
can import into idempotently and reversibly — no blocked seam.