BusinessOfficialVerified
Platform Cutover
by Skill Me
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.
When your AI uses it
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.This is the skill's description: the text your AI reads to decide when the skill applies.
social-mediamigrationautomationops
Read exactly what your AI will be told
platform-cutover/SKILL.md
---
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).