# Roo Code is retired: preserve a local workflow before migrating

Preserve an existing Roo Code local workflow after its official retirement by inventorying rules and model choices before evaluating a replacement.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/roo-code-retired-local-workflow-migration/
Language: en

Roo Code’s official repository is archived, and its README states that the extension shut down on May 15. Treat an existing setup as a migration case, preserving useful rules and task knowledge rather than recommending a new Roo installation.

## The concrete application boundary

The repository archive date is May 15, 2026. Its historical documentation describes Code, Architect, Ask, Debug, and custom modes, along with MCP use. Those concepts can help identify what an existing user relied on, but an archived feature list is not a promise of current maintenance or service availability. Separate the reusable part of the workflow from product-specific state: repository instructions, desired review boundaries, local model identity, and known task examples can be documented independently. Secrets and provider credentials are not ordinary instruction text and should not be copied into migration notes. A fork or another product has its own support and configuration boundaries ([Roo Code official archive](https://github.com/RooCodeInc/Roo-Code)).

## A practical route

Inventory the existing installation without broadening its permissions or starting a new long-running task. Preserve the relevant project rules and describe each custom mode by purpose and allowed actions. Record the local runtime and actual model identifier separately. For a replacement candidate such as Cline, follow its current local-model documentation and recreate only the capabilities needed for one trial. Begin with read-only source explanation, then a small reviewed edit. Do not import an unknown settings file wholesale or assume another product understands Roo-specific mode definitions ([Cline local model overview](https://docs.cline.bot/running-models-locally/overview)).

## A worked example

A user relied on an Ask mode for explanations and a custom mode that could edit documentation but not source code. The transferable requirement is that difference in action scope, not the old mode name. Recreate an explanation workflow and a narrowly scoped documentation task in the candidate application. Compare the proposed file action and actual diff with the preserved requirement before using it on ongoing work. Keep the local model unchanged during the first trial so two independent changes are not mixed.

| Check | Record |
| --- | --- |
| Retained knowledge | Project instructions, mode purposes, and a harmless example task. |
| Retained model path | The local runtime and real model identity, without credentials in notes. |
| Replacement trial | One explanation and one reviewed documentation edit under the new application’s controls. |

## Reading the failure correctly

A successor’s familiar interface does not prove compatible checkpoint history, credentials, or permissions. Cline checkpoints, for example, have their own documented workspace scope. A migration should not claim that old conversation history or snapshots automatically transfer. Preserve the old evidence until the replacement’s actual behavior is understood ([Cline Checkpoints](https://docs.cline.bot/core-workflows/checkpoints)).

## What completes the check

The durable result is a documented local workflow that can be evaluated independently of the retired extension. Roo’s archive establishes the need to reassess the tool; it does not establish automatic compatibility with any particular alternative.

Related background: [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/), [Coding LLMs on 12GB VRAM: Budget Context and Headroom](/journal/coding-llm-12gb-vram/).