Switch from Factory AI to Continuum without losing work

First decide whether you should switch

A migration is justified when the operating model has already moved away from Factory. Common signals are developers opening Claude Code or Codex directly, Droids duplicating subscriptions the company already buys, a small team using little enterprise governance, or a need to see several official agents and their quota states in one place. The change is harder to justify when Factory-specific controls and deployment contracts are active requirements.

Honest reasons to leave Factory

• The team already works in official agent CLIs. Paying for Factory while most accepted work comes from Claude Code, Codex, Cursor agent, or OpenCode can create a second agent layer without enough incremental value.
• The organization is too small for the platform surface. SSO, deployment patterns, model policy, OTEL, and an adoption program are valuable only when somebody owns and uses them.
• You want provider choice at the agent layer. Continuum keeps official agent identities separate in one sidebar, so a Claude session stays Claude Code and a Codex session stays Codex.
• You need worktree isolation and review panes more than an autonomy program. Continuum attaches chat, plan, diff, pull request, terminal, and artifacts to a session without making Droid the runtime.
• You already pay for the model work. The Continuum app is free and runs the subscriptions or keys already attached to the official agents.
• You need quota truth across accounts. Continuum shows live five-hour and weekly gauges per supported subscription and keeps accounts isolated on the same host.
• You want native phone control. Existing Continuum site content documents iPhone and Watch clients for approving plans, interrupting work, reading diffs, and following sessions on owned hosts.
• You want local spend by repository. Continuum parses local agent history and prices activity into a ledger by repository, provider, model, and day.

These reasons are strongest for individuals and small teams with an established CLI stack. They weaken as the requirement moves from operating agents to governing an enterprise autonomy platform. Be precise about the problem being removed. A migration that saves a seat and creates an internal policy project is a poor trade.

Honest reasons to stay on Factory

• Droid quality and behavior are the reason you bought Factory. Continuum does not ship a replacement model or first-party autonomous engineer. It runs other agents.
• Specification Mode is part of change control. Factory provides a formal read-only planning phase, generated acceptance criteria, and approval before implementation.
• Droid Computers carry production value. Persistent managed computers and BYOM targets can hold complex services, packages, configuration, and runtime state across sessions.
• Factory Missions run multi-day goals. Continuum can run several sessions in parallel, while Factory supplies a parent orchestration system for decomposition and workers.
• Enterprise deployment is contractual. Factory documents cloud-managed, hybrid, and fully airgapped options. Continuum's local-first host model is a different architecture.
• Identity and policy are centralized in Factory. SSO, SCIM, model and tool controls, network policy, audit trails, and data terms can be central to the security approval.
• OTEL is part of the internal platform. Factory emits organization-level metrics and traces into customer observability systems. Continuum's local ledger serves a narrower operating need.
• A named vendor team owns adoption and support. Enterprise Factory includes account and engineering support structures that a free workbench does not claim.

Inventory the Factory workflow before touching tools

Create one row for every recurring Factory workflow. A session name is insufficient. Record the trigger, owner, repository, task class, instruction sources, selected model, environment, secrets, network access, autonomy level, approval point, test contract, artifacts, pull-request behavior, telemetry, budget, and rollback. Mark whether the workflow is interactive, headless, computer-backed, or a Mission.

Export saved specifications, skills, custom Droid prompts, hook behavior, environment setup, automation definitions, audit reports needed for retention, and links to accepted pull requests. Move durable facts into repository documentation. Preserve transcripts only when policy allows and they carry decision history unavailable elsewhere.

Map Factory concepts to the new operating model

Some mappings are substitutions. Others are deliberate scope reductions. Document each reduction and obtain the right owner's approval. A Mission becoming three human-scoped sessions changes responsibility. A Factory-managed computer becoming an owned Linux host changes patching, availability, credentials, and incident ownership.

Step-by-step migration

Build a fair shadow pilot

Use at least four task classes: an interactive bug, a feature with explicit acceptance criteria, repeated maintenance, and a long task on a remote environment. Include one failure case, such as a missing dependency or contradictory test. A pilot containing only clean feature work rewards demos and hides operations.

Keep the same human reviewer for matched tasks where possible. Review style can move the result more than agent quality. Record which provider and model Continuum ran, because a multi-provider workbench can otherwise appear inconsistent for reasons hidden in routing.

Rollback plan

Keep Factory identities, integrations, and the minimum required computers active until Continuum completes a release cycle and the retained audit evidence is accepted. Preserve versioned setup for both paths. Store the mapping from Factory sessions to branches and pull requests. Avoid rotating a shared secret until the replacement credential has passed the same workflow.

• Rollback trigger: repeated environment failure, missing audit evidence, review time above target, quota interruption on critical work, host reliability below target, or an unmet security control.
• Rollback action: stop new Continuum dispatches for the task class, preserve current worktrees, return new tasks to the recorded Factory workflow, and review the failed contract.
• Data handling: retain or delete transcripts, specs, logs, and computer state according to the signed policies on both products.
• Credential handling: revoke temporary pilot tokens, rotate any credential exposed more broadly than intended, and verify schedules are disabled in only one system at a time.
• Git handling: land, archive, or close every pilot branch. Never leave both systems automatically updating the same branch or pull request.

Rollback is a normal migration feature. A reversible cutover gives the team permission to test real work. An irreversible big-bang move encourages shallow validation and hides failures until the deadline removes choice.

After cutover: the new operating contract

Publish a one-page operating contract. Name the approved agents and accounts, task-to-provider routing, worktree requirement, plan approval threshold, allowed hosts, secret owners, quota owners, review standard, merge authority, incident path, and transcript retention. Include the explicit capabilities the team gave up from Factory and the owner of each compensating control.

Questions people ask

Keep reading