To turn Cascade off for good means migrating everything it held: memories, workflows, rules, hooks, MCP and auto-execution settings. The volume is daunting, and two equally bad impulses arise - either give up and keep Cascade forever as insurance, or flip a switch and hope the needed things somehow move on their own. Both postpone the work rather than doing it.

The naive model of migration is copying. It seems enough to move memories and workflows to a new place, and Devin Local will pick up where things left off, just under a new name. The expectation again rests on a similarity of vocabulary: there were rules and memory, here there are rules and memory, so the move is mechanical.

It breaks on the fact that explains the wizard's very existence: memories and workflows are not supported as such in Devin Local. They cannot be copied - they must be translated into another form, above all into skills. That is exactly why the product has a Cascade Migration Wizard: migration here is a translation from one model into another, not a move of files between folders.

The wizard is launched by the command Devin: Open Cascade Migration Wizard and, in one guided flow, brings over your workflows and memories, helping turn critical memories into skills. This is a starting point, not a finish: per the documentation, after the migration you should open the Customizations section and review each source - to make sure exactly what is needed moved over, and in the right form. It is worth remembering that the wizard helps with the move but does not relieve you of responsibility for the contents: what exactly became a skill, and whether anything extra leaked into it, is visible only on a manual review of Customizations.

What helps next is not a sequence of clicks but a transition matrix: which Cascade concept maps to which target in Devin Local and what action is required. The table below is exactly such a map. It must be read row by row and as a list of decisions, not of auto-replacements: each row calls for a rethink, not a transfer.

Let us walk the rows. A memory moves into a rule or a skill - but with filtering: facts are separated from secrets, and the latter have no place in a permanent context. A workflow becomes a skill to which tools, permissions and a way to verify the result are added explicitly. A rule goes into AGENTS.md or .devin/rules with its always-on part trimmed, so as not to bloat the permanent context. A hook is carried over with its events and outcome re-checked. MCP - with re-authentication and narrowed grants. Auto-exec is translated into permissions and a sandbox, carrying over the intent, not the syntax. None of these rows reduces to renaming a folder: each holds a decision a human makes deliberately - what to keep, what to discard, what to rewrite for the new permission model.