Migrate from Elementary
Elementary runs on top of dbt, so the migration path is the dbt-tests path. Translate your schema.yml entries to ODCS with the community dbt-odcs package, then paste into AnomalyArmor.
Use the dbt recipe
The full recipe, install instructions, and mapping table live at /migrate/dbt. It covers the four built-in dbt generic tests: not_null, unique, accepted_values, and relationships.
Elementary-specific notes
- Elementary anomaly monitors. Elementary's anomaly-detection tests (e.g.
elementary.volume_anomalies,elementary.freshness_anomalies) are macros, not standard dbt tests. They do not translate directly to ODCS. AnomalyArmor auto-baselines equivalent monitors (freshness, volume, null rate) against the same tables after import — you can compare to the Elementary versions and drop the Elementary macros once parity is confirmed. - Elementary result tables. The tables Elementary writes into your warehouse (
dbt_test_results,alerts, etc.) are not needed by AnomalyArmor. They are safe to drop once Elementary is removed from your dbt project. - Elementary observability site. If your team relies on the Elementary-generated HTML site as a reporting artifact, AnomalyArmor does not replace that. Decide whether that workflow is worth keeping Elementary running alongside.
Running both during migration
Most teams run Elementary and AnomalyArmor in parallel for a week. Elementary keeps firing the monitors you trust; AnomalyArmor runs silently and builds baselines. When you are satisfied that parity is in place for the signals you care about, flip the alert destinations and remove the Elementary anomaly monitors from your dbt project.
Start with the dbt recipe
Elementary migration
Frequently Asked Questions
No. Because Elementary runs on top of dbt, the import path is the dbt-tests path: translate `schema.yml` entries to ODCS using the `dbt-odcs` community package, then paste into /migrate/soda. This page inlines the dbt recipe so you do not have to hop.