Over time working in Cascade, memories accumulate - short notes the agent creates itself when it decides the context is worth remembering. Eventually there are many of them, they look like a project's knowledge base, and the temptation arises to rely on them as the team's durable memory. It is exactly this temptation that trips you up on the move to Devin Local.
The naive move is to assume that since memories have accumulated, the knowledge is already saved and nothing needs to be migrated: the new agent will pick them up just as the old one did. In that picture a memory is a shared, common and eternal fact about the project, and it is enough to simply keep working.
It breaks on three properties of memories that are documented directly. They are created automatically and bound to a workspace - in another workspace they do not exist. They are stored locally in ~/.codeium/windsurf/memories and live only on your machine. They are not under version control and do not reach the repository. And, by the documentation's direct warning, they may be incomplete - relying on auto-memory as the sole source is unwise.
Hence the principle of migration: repeatable knowledge is moved from auto-memory into a verifiable form - a reviewable rule or skill. The difference is that a rule and a skill live in the repository, go through review, are versioned and are visible to the whole team, whereas a memory remains a private guess of one agent on one machine. Reviewable is the key word: a rule and a skill can be read, discussed in a pull request and rolled back like any code, while a memory arises and changes unnoticed, outside anyone's review. What is migrated is not text for its own sake but exactly this property of verifiability - it is what separates team knowledge from a personal guess. Migration is turning a personal note into a shared contract.
The home for rules also changed, and both addresses are worth knowing. The modern preferred path is .devin/rules/.md; the legacy path .windsurf/rules/.md is still read, so old rules do not disappear in a day. AGENTS.md is processed by the same rules engine and is handy as a shared portable minimum: the root file is always-on, nested ones are picked up as the agent accesses files in their directory. The subtlety here matters: per the docs the rule files in .devin/rules and in legacy .windsurf/rules are both loaded at once, so the old rule is not overridden by the new one but acts alongside it - and on an overlapping topic you get two competing rules. So during a migration the legacy copy should be either deleted or brought into line, not left as a forgotten duplicate.
Not every memory needs to be migrated, and some should be deleted. It helps to sort the content by type and assign each its home in advance rather than deciding at the moment of migration. Below is such a layout: what kind of knowledge is in a memory and where to route it.
| Memory content | New home |
|---|---|
| A short durable constraint | AGENTS.md / rule |
| A multi-step procedure | Skill |
| A secret or token | Do not migrate; secret manager |
| A temporary hypothesis | Issue/plan, then delete |
A separate row in this table is about what is not migrated at all. A secret or token from a memory does not move into a rule, a skill or AGENTS.md: the repository and a portable file are the wrong place for a secret, its road leads to a secret manager. A temporary hypothesis does not deserve a permanent home either - its place is an issue or a plan, after which the memory is deleted.
The cost of a wrong migration is two-sided. Leaving knowledge only in auto-memory means losing it when the machine, workspace or agent changes, and getting a Devin Local that "forgot" what the team considered known. Moving the excess into the repo - a secret, a stale hypothesis, a one-off remark - means littering the always-on context and, in the case of a secret, carrying it outside the security boundary. An error in either direction costs either lost knowledge or a leak. Always-on is especially dangerous: a rule marked as always active enters the context of every turn, so only truly permanent constraints are moved there, while everything situational is expressed as a skill with triggers or as a glob rule for its own directory.
You should check the migration not by the fact of "copied" but by the properties of the new home. Whether the rule is opened in the repository and has passed review. Whether it lies on the current path .devin/rules rather than only in the legacy one. Whether a secret leaked into the text of the rule - this is caught by the same grep over the diff as any secret before a commit. Whether the source memory is empty after the move, so the knowledge does not double in two sources with different fates.
The typical failure is mistaking auto-memory for migrated knowledge. "Devin Local does not know the rule" - because it stayed a memory and did not become a rule. "The rule is not read" - because it lies in the legacy path while a higher-priority .devin/rules with different content sits alongside. "A secret got into git" - because a memory was moved verbatim, together with the token. The sign is the same: knowledge is considered shared while it still lives locally and privately. First ask where the fact physically lies and who sees it - the answer is usually right there.