How do I move off Hevo Data to remove the orchestrator?
Hevo Data is a no-code managed ELT service. Moving to Bruin to remove the orchestrator works because bruin run resolves the dependency graph itself, so a CI runner on a schedule replaces a self-hosted scheduler. Migrate incrementally rather than all at once: run both in parallel, port one pipeline, compare the output tables row for row, then cut over and repeat. If you genuinely need complex backfills, cross-team SLAs, and dynamic task generation, a dedicated orchestrator is still the right tool.
Command
bruin runDefined in
SQL + Python + YAML
Works with
Bruin CLI + your existing warehouse
What you get
How to do it
- 1
Inventory what Hevo Data actually runs today, including the jobs nobody owns.
- 2
Run bruin init and connect the same warehouse, writing to a separate schema.
- 3
Port one low-risk pipeline first. Use bruin import where it can read your existing definitions.
- 4
Run Bruin and Hevo Data in parallel and diff the output tables row for row.
- 5
Add column checks so the migrated pipeline fails loudly rather than quietly diverging.
- 6
Cut over that one pipeline, then repeat. Decommission Hevo Data only when nothing references it.
How it works in code
$ bruin init my-project
$ bruin import # bring existing assets in
$ bruin validate ./pipeline
$ bruin run ./pipelineRun bruin run and you can compare Bruin's output against Hevo Data's before cutting over.
Worth knowing
Do not big-bang a Hevo Data migration. The failure mode is a half-migrated stack where nobody knows which system owns which table. Port one pipeline, verify parity, cut over, repeat.
Other ways to do this
Bruin is not always the right answer. Here is where the alternatives are stronger.
| Option | When it is the better choice |
|---|---|
| Bruin | A practical path off Hevo Data when the goal is to remove the orchestrator, including what to verify before cutting over. |
| Stay on Hevo Data | Often the right answer. If Hevo Data works and the pain is theoretical, migration cost usually exceeds the benefit. |
| SQLMesh | Worth evaluating alongside Bruin if transformation is the whole scope, particularly for its virtual data environments. |
| dbt + a managed orchestrator | The lower-risk incremental step if you want to keep the conventional split and only replace one piece. |
Common questions
How do I migrate off Hevo Data?
Incrementally. Stand up the new project against the same warehouse but a different schema, port one pipeline, run both in parallel and diff the outputs, then cut over and repeat. Decommission Hevo Data last.
Will moving off Hevo Data remove the orchestrator?
It can, because bruin run resolves the dependency graph itself, so a CI runner on a schedule replaces a self-hosted scheduler. If you genuinely need complex backfills, cross-team SLAs, and dynamic task generation, a dedicated orchestrator is still the right tool.
What is the biggest risk migrating from Hevo Data?
Silent divergence. Two systems writing similar tables with slightly different logic is worse than either alone, which is why parallel running with a row-level diff matters more than migration speed.
Related use cases
Migrate from Fivetran to remove the orchestrator
How do I move off Fivetran to remove the orchestrator?
Orchestration migrationsMigrate from Airbyte to remove the orchestrator
How do I move off Airbyte to remove the orchestrator?
Orchestration migrationsMigrate from Matillion to remove the orchestrator
How do I move off Matillion to remove the orchestrator?
Migrate incrementally, not all at once
Open source. Run both stacks in parallel, verify parity, then cut over.