Migrating from dbt Cloud
Move your existing dbt Cloud setup into dbdeux with a guided, reviewable wizard. You upload an export of your account, see exactly what will be created before anything changes, and apply the import in one idempotent step.
Organization owners and admins run the migration from the Organizations area.
How it works
The wizard walks through four steps on a full-width page, with a side rail that always shows where you are and keeps the next action in view. Nothing is created until the Apply step:
- Upload and validate (read-only checks): Export your dbt Cloud account with the dbdeux migration tool and upload the manifest it writes. It captures your projects, environments, and jobs as metadata only; secret values (warehouse passwords, keys, tokens) are never included. Validation starts by itself as soon as the file is in, with an animated card showing each check, and findings grouped by severity in a scroll area.
- Choose what to import (projects, jobs, people): Pick exactly what comes across. For each project you choose what happens if it already exists in dbdeux, pick its jobs from a list, and set how dbdeux reaches its repository. See Choose What to Import.
- Review plan and mapping (dry run, nothing written): Every item is listed with the action dbdeux would take, and each dbt Cloud field is mapped to the dbdeux setting it becomes.
- Apply (safe to re-run): dbdeux imports what you chose and shows its progress live, stage by stage, from what the server has actually recorded. Invitations to your people are sent last.
Each step names what it will and will not do before you take it, so the page reads as a plan rather than a form. Only Apply writes anything.
Choose What to Import
dbdeux matches each dbt Cloud object by where it came from, not only by its name, so nothing is merged silently. When a project with the same name already exists, you pick one of three modes:
| Mode | What happens |
|---|---|
| Skip | The existing project is left exactly as it is |
| Add what is missing | Environments and jobs that are not there yet are added to the existing project; nothing already there is changed |
| Import as a copy | A new project is created under a new name, next to the existing one |
If an object has the same name but came from a different dbt Cloud object, the plan flags it as a name collision and asks you to pick one of these modes instead of guessing.
For the repository you choose a saved Git credential, including a GitHub App credential, or public access. Connections whose secrets you have not entered yet come across as pending credentials: they are created with their settings, and runs and tests wait until you add the secret.
Apply You Can Watch, Results You Can Trust
Apply runs on the server and keeps going if you leave the page. The progress card reads what has really been recorded, so a stage turns done only when its items exist. If no progress is reported for five minutes, the card says so plainly, and nothing recorded so far is lost.
The result opens with what was not done. If something failed, it says how many and groups the reasons, so a partial import never looks like a success. Each import is kept under import history with its counts: created, updated, already existed, skipped, and failed.
Re-apply finishes a partial import. It fills the gaps, adds what is missing to projects that already came across, and never duplicates anything.
If the import would take your organization past its plan's scheduled-job allowance, both the plan review and Apply stop and say so before anything is created, with how many jobs your plan allows and how to raise it.
From Import to Running Jobs
- Repository access is checked first, with Test access before Apply. A project only gets its environments and jobs once its repository has been cloned. If a clone fails, the project shows it in the project picker with Retry the repository clone, where you can pick another saved credential, a GitHub App installation, or public access.
- Target schema per environment: for warehouses that need one, Choose what to import has a Schema field for each environment, with a note when the export did not carry one.
- Jobs arrive paused so nothing runs against a connection that is not ready. A Next steps checklist walks you through adding the missing credentials, then resumes every imported job in one click. A job that still needs something is skipped with the reason, and the others start on their dbt Cloud schedules.
- Apply picks itself back up: if the server stops mid-import, Apply resumes automatically, up to three times, from what was already recorded.
- Connections are matched within the workspace first, and one from another workspace is reused only when it points at exactly the same warehouse, which the result names.
Getting the export
The migration tab hands you the tool rather than sending you to look for it. Download the CLI gives you the export tool, with the three commands to run underneath it:
- Unzip and install the tool
- Copy the example configuration, then fill in your dbt Cloud service token and account id
- Run the extract command, which writes the manifest file
The extract command is shown with a copy button, so it goes straight into your terminal. The tool runs on Windows, macOS, and Linux, and writes its files as UTF-8 so names with accents or other non-English characters come through intact. The tool reads metadata only, and your dbt Cloud credentials stay on your own machine.
Back in dbdeux you can drag the manifest onto the page, pick it from your file browser, or paste it in. The file is parsed as you provide it, so a wrong or truncated file is caught immediately instead of at the end of the wizard.
Knowing the size of the move before you start
Validation summarizes the export as counts you can sanity check at a glance: how many projects, environments, and jobs were found, and how many secrets you will need to re-enter afterward. If that last number is the one that makes you wince, it is better to see it now than halfway through a Friday afternoon.
The dry-run plan is filterable, because a plan with several hundred lines is only useful if you can narrow it. Filter to what will be created, what already exists and will be skipped, what is not yet supported, or what will need a secret afterward, and read just that slice. The same counts appear as tiles above the list, so the shape of the import is clear before you read a single row.
After you apply, the result is reported the same way: created, updated, already existed, skipped, and failed, with a plain list of what to do next rather than leaving you to work out where you stand.
What gets imported
- Projects and their repository links. Repositories that dbt Cloud stores as SSH addresses are converted to the HTTPS address dbdeux connects with
- Environments with their variable names (you re-enter secret values afterward)
- Warehouse connections for the adapters in your account
- Scheduled jobs, including their commands and cron schedules. A schedule for the last day of the month (
L) comes across as written and runs only on the month's real last day - Jobs with several steps, such as
dbt deps,dbt run, thendbt test, keep every step in the same order (up to 21 steps of dbt commands) - Manual jobs that have no schedule in dbt Cloud, imported as manual jobs you can run on demand
Some dbt Cloud jobs cannot come across exactly as they are, and the dry-run plan says so before anything is created:
| In dbt Cloud | In dbdeux | What to do |
|---|---|---|
| A step that is not a dbt command, or more than 21 steps | The steps are combined into one dbt command, with a warning in the plan | Review the command after the import |
Safe by design
- Preview first: The dry-run plan shows every action before you commit, so there are no surprises.
- Idempotent: Re-running the import skips anything that already exists and fills in what is missing instead of creating duplicates, so a second pass is always safe.
- Jobs arrive disabled: Imported jobs are always created switched off. Nothing runs on a schedule until you review it and turn it on yourself.
- Secrets stay yours: The manifest carries only the list of secrets you need to re-enter, never their values. dbdeux shows you exactly which credentials to add after the import.
After the import
Once the plan is applied:
- Re-enter the secret values dbdeux flagged (warehouse credentials, tokens)
- Review the imported environments and connections
- Enable the scheduled jobs you want running
Your dbt project code moves with your Git repository, so your models, tests, and macros come across exactly as they are once the repository is connected.