Migration Decisions Should Be Costed as Build-vs-Buy Not UI-vs-UI

# Migration Decisions Should Be Costed as Build-vs-Buy Not UI-vs-UI ## Claim When a client proposes leaving a platform for a workflow gap it lacks natively, the decision should compare the full cost of the rebuild (retraining, dual contracts, data migration, ongoing dual-stack maintenance) against the cost of a scoped fix that closes the same gap in place — not a surface comparison of one platform's default admin UI against a competitor's polished one. ## Evidence **Source**: [[3. Resources/Literature Notes/Building a Real Editorial Workflow Without Leaving the Ecosystem Sarah Siqueira]] ## Scope & conditions - Holds when: the migration is driven by a workflow/UX complaint (missing approval pipeline, cluttered admin, no safe external preview) in an otherwise workflow-agnostic platform, and the gap is closeable with a scoped, maintainable build. - Breaks when: the driver is a genuine architectural need the incumbent platform structurally can't meet (omnichannel delivery, headless-first product requirements, performance at extreme scale) — there the UI comparison was never the real question, and no plugin closes it. ## Links - [[Product & Startup Instincts MOC]] — because applies-in: a build-vs-buy costing heuristic alongside the MOC's other platform/CMS-decision instincts. - [[3. Resources/Permanent Notes/The CMS Decision Turns on How a Site Is Edited Not What It Contains]] — extends: both anchor a platform decision in the actual workflow being served rather than a surface-level comparison, but that note decides static-vs-CMS by editing frequency while this one decides platform-vs-platform by rebuild cost. - [[3. Resources/Permanent Notes/A Vendor-Defined Decision Framework Predetermines Its Own Winner]] — applies-in: headless CMS vendors' better-funded sales teams shape the "you need us" framing the same way any vendor-defined comparison predetermines its own winner. - [[3. Resources/Literature Notes/Phase 3 Collaboration]] — evidence-for: WordPress core building native review/approval flows is itself a build-side answer to the same workflow gap this claim says to cost against a migration.