migrate-to-sent

Migrate to Sent plans and executes a migration from an incumbent CPaaS provider (Twilio, Sinch, Infobip, Vonage, or MessageBird/Bird) to Sent v3. It addresses the recurring, high-risk translation problems that every such migration hits, several of which pass tests but fail expensively in production - most notably that Sent's channel array is a broadcast list, so porting an incumbent's ordered fallback array multiplies cost by producing one message and charge per recipient-channel pair.

The skill works through five ordered translation problems: replacing ordered fallback with Sent's automatic routing; reconciling status vocabularies (including Sent-specific states like ROUTED, FILTERED, BLOCKED, and SCHEDULED that break naive retry logic and must not be retried when they represent consent or account gates); rewriting webhook signature verification, since each provider signs differently and no Sent SDK ships a verifier (Sent uses HMAC-SHA256 over id.timestamp.raw_body with constant-time comparison and a 300-second window); reconciling opt-out/suppression stores channel-agnostically rather than copying them; and mapping templates and tenancy. A cutover playbook defines seven phases with explicit exit gates (inventory, mapping, parallel build, verification, dual-run, staged cutover, decommission), rollback triggers, and comparison metrics, and an inventory_scan.py script scans a repository for provider SDK imports, endpoint URLs, signature header names, status strings, numeric error codes, and ordered channel arrays with migration classifications.

It targets engineers and architects replacing an incumbent messaging provider, translating provider code or webhook handlers to Sent, and planning phased, reversible cutovers with dual-run and rollback. The security guidance is defensive throughout (constant-time signature comparison, timestamp windows, preserving consent records), and it delegates receiver and routing detail to companion Sent skills.