Skip to main content
Migrating a legacy Attio workflow means rebuilding it in the new engine, testing it against real trigger data, and cutting over without duplicating writes. A legacy workflow is one built in Attio’s old automation builder, before the 2026 engine. You can no longer create new legacy workflows; existing ones keep running, and Attio says sunset notice will come “well in advance.” Treat each migration like replacing a piece of production software, not a one-click conversion. Inventory the legacy workflow, rebuild it, test it on real data, then swap the two over deliberately. The new engine is where the better pricing and the new capabilities live. You get agent blocks and the Execute code block. You also get several other additions:
  • Multi-trigger support.
  • Advanced variables.
  • Copy and paste across workspaces.
  • Retry, pause, and resume.
  • Custom blocks built with the App SDK.
None of that is a reason to rush a write-enabled workflow into production before it is proven. A write-enabled workflow is one that changes your data. A mistake there is harder to undo than a mistake in a workflow that only reads.
The new engine reprices everything. Keep Pricing changes open while you rebuild so a cheaper legacy step does not become an expensive one. For the full credit model, see Credits & pricing explained.

​
Migration order

Sequence the work so the highest-value migrations land first and the safe, low-value ones wait. Migrate in this order:
  1. High-volume workflows where the cheaper new pricing matters now.
  2. Workflows that use legacy research blocks, which the Web agent replaces.
  3. Workflows with many logic, delay, and lookup steps, which run free in the new engine.
  4. Workflows that operators touch daily.
  5. Low-volume back-office workflows.
Leave stable, low-value legacy workflows running until the high-value ones are done. A workflow that fires twice a month and writes nothing costly earns nothing by being rebuilt early.

​
Inventory the legacy workflow

Document the legacy workflow before you change anything. Once you start over, the new builder will not show you what the old one did. Capture each of the following:
  • The trigger and its trigger conditions.
  • Every block and every branch.
  • The variables passed between blocks.
  • The objects, lists, sequences, and apps the workflow touches.
  • The credit-heavy sections.
  • Whether the workflow writes to the same object or list that triggered it.
Screenshot the legacy canvas before you touch anything. That last point matters most. Whether the workflow writes back to its own trigger source decides whether a parallel run is safe. Flag it now rather than discovering it during cutover.

​
Rebuild and verify the new workflow

Ask Attio can recreate a legacy workflow in the new builder. Treat that draft as a starting point, not a guarantee. Rebuild with the assistant first. Then open the result and check every block against your inventory before you trust it.
1

Generate a first draft with Ask Attio

Ask Attio to recreate the legacy workflow in the new builder. The new workflow is created disabled, which is what you want. Keep it disabled until testing passes.
2

Confirm the trigger mapped correctly

Open the new trigger and check it matches the legacy intent. Renamed triggers are a common trap. The legacy Attribute changed trigger is now Attribute value changed, so confirm the right one was chosen.
3

Check every variable's source

Walk each block and confirm its variables read from the block you expect. A variable carries data from one block to the next. A draft can wire a variable to a wrong source that still looks plausible. You often see this only as an empty value when the workflow runs.
4

Confirm filters preserve the same logic

Compare each condition against the legacy version. The legacy If/else block is now If. A rebuilt branch can invert or drop a clause without an obvious error.
5

Re-check formatting and renamed options

Slack messages use standard Markdown in the new engine, so a message that relied on legacy formatting may render differently. Verify any renamed picklist options still map to the branches that depend on them.
6

Grant workflow write access

Confirm the new workflow has the write permissions it needs. Missing access usually looks like a broken block, not a broken migration, so check it before you blame the build.

​
Test with real trigger data

Test the new workflow against real trigger data before it touches production. Use test records wherever you can. Open the Runs tab and inspect each run, as covered in Runs, debugging & publishing. Check the following:
  • The inputs and outputs for each block.
  • The path the run actually took versus the path you expected.
  • The credit usage.
  • Any empty variables or yellow warnings.
  • The loop iteration behavior, if the workflow processes many records.
If you change the workflow after a failed run, trigger a fresh run to validate the fix. Retrying an old run replays the originally published version, so a retry will not pick up your edit.

​
Cut over safely

Cut over only once the new workflow matches the legacy output on real data. Switch the two deliberately rather than flipping them at once.
1

Publish the new workflow

Publish the new workflow so its current version is the one that runs.
2

Disable the legacy workflow

Disable the legacy workflow so the two cannot fire on the same trigger.
3

Fire one production-safe test

Trigger one production-safe test, such as a record you can later clean up, and confirm the new workflow handles it end to end.
4

Watch the first week

Watch failure notifications and credit usage for the first week. I check this daily for the first few days, then weekly through the first month.
Do not run old and new write-enabled workflows in parallel unless you are deliberately testing duplicate-safe behavior. Two enabled workflows on the same trigger both fire, so every write happens twice. That duplicates records, double-enrolls sequences, and burns credits silently.

​
Common migration surprises

Several legacy names and behaviors changed in the new engine. Watch for these when your rebuilt workflow behaves differently from the original:
  • The Attribute changed trigger is now Attribute value changed.
  • The If/else block is now If.
  • The Research record block is now the Web agent.
  • Prompt-completion work now belongs in the Custom agent block.
  • Slack messages use standard Markdown in the new engine.
  • Logic, delays, lookups, and round robin run free in the new engine.
  • AI blocks are now priced per token, not as fixed one- or ten-credit blocks. The Execute code block costs Variable (complexity-based).
  • Workflow write access is still explicit. Missing access often looks like a broken block, not a broken migration.
Per-workflow credit caps were removed in the new engine, so do not try to recreate one as a safety limit. For the full list of renamed and replaced blocks, see Block changes reference.

​
See also

Source: Migrate your legacy workflows, Attio Help Center. Last reviewed against the Attio Help Center, June 2026.