Platform Cutover

---
name: Platform Cutover
description: Migrate an automated social operation from one scheduler platform to another without dropping posts — an overlap window with split channel ownership, a dated cutover keyed to the last scheduled draft, per-channel handoff verification, and a single governing takeover document. Use when someone says "we're moving from Typefully to Postiz", "migrate our scheduler", "switch social tools without losing the queue", or is running two schedulers during a transition. Do NOT use for first-time scheduler setup — use social-stack-bootstrap; for ongoing queue maintenance during or after the migration, use scheduling-agent-loop.
---

# Platform Cutover

Scheduler migrations fail at the seams: a channel nobody owns for three days, a draft that publishes on the old platform after the new one took over, media stranded in the old library. This skill makes the seam explicit and dated.

## The governing artifact

Write one takeover document (e.g. `TAKEOVER.md`) at the start. It is the single source of truth for the entire migration — both platforms' workflows, every agent run, and every human step defer to it. If the migration plan changes, the document changes first. Contents:

- **Cutover date** — the day the new platform owns everything.
- **Ownership table** — per channel: who owns it today, who owns it after cutover, and the exact date ownership flips. During overlap, a channel has exactly one owner. Two schedulers posting to one channel is the failure this table exists to prevent.
- **Last-draft mapping** — the final scheduled post on the old platform per channel, by ID and send time. The new platform's queue starts strictly after it.
- **Manual boundaries inherited from both stacks** (cite each platform's STACK.md).

## Workflow

**1. Bootstrap the new platform first.** Run social-stack-bootstrap against it fully — tool probe, capability map, STACK.md — before any channel flips. Never cut over onto an unprobed stack.

**2. Design the overlap window.** Pick a window (1–3 weeks) where the old platform runs down its scheduled queue while the new platform takes new channels or new scheduling. Prefer flipping whole channels over splitting a channel's timeline. Natural split: new platform immediately owns channels the old one never served, and takes over the rest on the cutover date.

**3. Anchor the cutover to the last draft.** Set the cutover date after the final already-scheduled old-platform draft lands. Do not orphan scheduled work — either let it run down or explicitly migrate and delete it (with authorization; see scheduling-agent-loop's rule).