Every path below is derived from the tools' own declared migration sources and destinations — when both the source and the destination confirm the move, its spec diff is one click away. Each card names why the switch happens and what changes about the team's daily workflow. Full hand-written playbooks (effort cost, blast radius, what doesn't survive the move) are a layer we add on demand, not a promise stamped on every row.
If teams don't actually consider both tools in the same buying cycle, the playbook is theoretical. The pairs below come from each tool's declared migration paths — the editorial bar is that a move has shown up in practice often enough to be named.
Lateral moves between tools doing the same thing aren't interesting. The playbooks worth writing shift the team's daily workflow — OSS to managed, code-first to GUI-first, dbt-native to warehouse-side, or vice versa.
When a full playbook gets written, the effort estimate — days, weeks, or quarters — comes from teams who made the move, not from marketing, and it says what doesn't survive. Until then a path here is exactly what the data supports: a real, declared relationship with the spec diff attached, and no invented prose.
Both tools live in the catalog discovery cluster — usually a workflow shift between paradigms (code-first vs. GUI, warehouse-side vs. dbt-native).
Both tools live in the catalog discovery cluster — usually a workflow shift between paradigms (code-first vs. GUI, warehouse-side vs. dbt-native).
Both tools live in the catalog discovery cluster — usually a workflow shift between paradigms (code-first vs. GUI, warehouse-side vs. dbt-native).
Both tools live in the catalog discovery cluster — usually a workflow shift between paradigms (code-first vs. GUI, warehouse-side vs. dbt-native).
Teams moving from a self-hosted Elementary setup to Monte Carlo's managed surface — typically scale, reliability, or the demand for non-warehouse sources.
Teams moving from a self-hosted Great Expectations setup to Anomalo's managed surface — typically scale, reliability, or the demand for non-warehouse sources.
Teams moving from a self-hosted Great Expectations setup to Soda's managed surface — typically scale, reliability, or the demand for non-warehouse sources.
Cross-cluster move — typically a re-platform where DataHub owns capabilities Marquez doesn't prioritize.
Cross-cluster move — typically a re-platform where OpenMetadata owns capabilities Marquez doesn't prioritize.
Playbooks get commissioned based on reader demand. If you're evaluating a switch we haven't tracked, tell us — we'll prioritize, interview teams who've made the move, and publish. When both tools agree the move happens, the page upgrades from planned to draft.
A tool that declares frequent_migration_sources or frequent_migration_destinations registers its pair here on the next build.