How the estimates work
The calculator produces estimates, not exact figures. Every team is different. The goal is to give engineering managers a defensible framework for the decision, not a precise invoice.
1. Context file migration
Each AI coding tool uses its own context format: CLAUDE.md, .cursorrules, .github/copilot-instructions.md, codex.md. These files accumulate over months. They contain project-specific instructions, coding conventions, architectural decisions, and team preferences.
Migration is manual. There is no automated converter between formats. Time scales logarithmically with months on the tool: the first 3 months of customization take longer to migrate than months 6–12, because early customizations are more fundamental.
Base estimate: 1.5 hours per engineer, multiplied by tool complexity (1–3) and a log-scaled months factor.
2. Workflow reconfiguration
Keybindings, IDE extensions, terminal aliases, CI hooks, pre-commit configurations, team conventions around when and how to use the tool. Each engineer reconfigures independently.
Base estimate: 1.5 hours per engineer per complexity point of the target tool. More complex tools (Claude Code, with hooks and MCP integration) take longer to configure than simpler ones (Copilot).
3. Team retraining
Engineers who were expert-level on the old tool start over at beginner on the new one. New prompting patterns, new capabilities, new failure modes, new ways to get the tool to do what you want.
The longer the team has been on the current tool, the more ingrained the habits. Switching after 12 months costs more in retraining than switching after 2 months, because the old patterns are more deeply embedded.
Base estimate: 3 hours per engineer per complexity point, scaled by a habit factor derived from months on the current tool.
4. Productivity dip
The largest cost and the one most often ignored. During the transition period, engineers are less productive than they were on the old tool and less productive than they will be on the new tool. They're in the valley.
Based on observed patterns from teams that have made this switch: the dip lasts 3–6 weeks depending on tool complexity, and reduces effective output by 12–21% during that period.
Estimate: (3 + complexity) weeks × 40 hours/week × (12% + complexity × 3%) capacity loss, per engineer.
5. Break-even timeline
Total switching cost divided by weekly productivity gain from the new tool.
Weekly gain = team size × 40 hours × hourly rate × (productivity gain % / 100).
The productivity gain input is the most important variable and the hardest to estimate honestly. Vendor benchmarks run on toy problems. Real-world gains on production codebases are typically 5–20%. If you're using a vendor's claimed 40% gain, the break-even will be optimistic.
Each tool is assigned a complexity score (1–3) that reflects how much configuration, customization, and workflow integration it requires. Higher complexity = more to migrate and more to learn.
Claude Code scores 3 because it has the most surface area: hooks system, MCP integration, CLAUDE.md format, permission model, and sub-agent configuration.
The productivity dip duration and magnitude are based on observed patterns from engineering teams that have made these switches, including a 600-engineer company that switched tools 3 times in 9 months.
Context migration time estimates are based on the actual time required to convert between CLAUDE.md, .cursorrules, and Copilot instruction formats, measured across several real migrations.
Retraining estimates are based on the time for engineers to reach their previous productivity level on a new tool, observed across teams of 5–50 engineers.
The methodology is open source. If you have data that would improve the estimates, open an issue or PR on GitHub.
These estimates do not account for: team seniority distribution, existing documentation quality, whether the team has a dedicated DevEx function, or organizational change management capacity.
The productivity gain input is entirely user-supplied. The calculator cannot validate whether your expected gain is realistic for your codebase and team.
Switching costs for teams already using multiple tools simultaneously are not modeled.
The estimates assume a full team switch. Partial rollouts (pilot → gradual expansion) have lower switching costs and are generally recommended.