Cost to add TypeScript to a JavaScript codebase

The cost to migrate JavaScript to TypeScript in 2026 typically runs $2,000 to $80,000 in engineer-weeks, depending on codebase size. A 10k-LOC app is one senior-engineer week. A 100k-LOC product is 6 to 12 weeks. A 1M-LOC monorepo is a multi-quarter project. AI-assisted file-by-file migration with Claude Code or Cursor cuts those estimates by roughly 3-4x compared to a fully manual rewrite.

That headline range is the answer most teams want. The interesting question is what actually drives the bill, where teams overspend, and which pieces you should never let an AI touch unsupervised. This post breaks the cost down by codebase size, walks the incremental migration patterns that work in 2026, and gives an honest call on when to hire help versus do it in-house.

What you're actually paying for

A TypeScript migration is not "rename .js to .ts and ship it." If it were, the Airbnb team would not have built ts-migrate, and Stripe would not have spent multiple quarters preparing the single pull request that converted 3.7 million lines of Flow to TypeScript on March 6, 2022.

You are paying for five distinct workstreams:

1. tsconfig posture. Pick strict, noImplicitAny, moduleResolution, target, and library settings. Wrong choices here cost weeks later.
2. File-by-file conversion. The actual .js to .ts work, including reading the file, inferring types, and resolving the inevitable any pile.
3. Strict ratchet. Turning on --strict flags one at a time and clearing the resulting errors without freezing feature work.
4. Test migration. Often Jest to Vitest, plus type-aware test helpers.
5. CI changes. Typecheck step, faster compilers (TypeScript 7.0, swc, esbuild), build-matrix updates.

Skip any of these and you ship "TypeScript" that is mostly any with extra steps. The Sentry team called the temptation to refactor mid-migration their most expensive trap; they explicitly froze refactors until 100% conversion to keep the bill under control.

Cost breakdown by codebase size

Real numbers from real migrations, mapped to engineer-weeks at Cadence's locked weekly rates (junior $500, mid $1,000, senior $1,500, lead $2,000):

Codebase size	Engineer-weeks (manual)	Engineer-weeks (AI-assisted)	Cost at senior tier (AI-assisted)	Realistic timeline
10k LOC (small SaaS, single app)	2 to 4	1 to 2	$1,500 to $3,000	1 to 2 weeks
50k LOC (mature product, one app)	8 to 16	3 to 5	$4,500 to $7,500	4 to 6 weeks
100k LOC (multi-app or monorepo slice)	18 to 30	6 to 12	$9,000 to $18,000	6 to 12 weeks
500k LOC (large monorepo)	80 to 120	25 to 40	$37,500 to $60,000	1 to 2 quarters
1M+ LOC (Stripe, Airbnb scale)	300+	80 to 150	$120,000 to $225,000	2 to 4 quarters

The "AI-assisted" column assumes Claude Code or Cursor running in agentic mode against the repo, with a senior engineer reviewing every pull request. Patreon's seven-year migration of 11,000 files, documented in their 2026 retrospective, showed dramatic acceleration in 2025 once Claude and Cursor matured. The first 60% took five years; the final 40% closed in roughly twelve months.

For reference points outside Cadence: Sentry shipped 100k LOC across 1,100 files with about a dozen engineers over 18 months. That is 200 engineer-months for what a small Cadence team running AI-native tooling would now estimate at 40 to 60 engineer-weeks. The 4x to 5x compression matches what we hear from founders running similar work in 2026.

Incremental migration patterns that actually work

The teams who finish migrations on budget all do the same thing: they let JavaScript and TypeScript coexist, then ratchet strictness. The teams who blow the budget try to cut over in one branch. Here is the playbook that wins.

Step 1: turn on allowJs and checkJs

Set "allowJs": true and "checkJs": false in tsconfig.json so TypeScript happily compiles your existing .js files without complaining. This is non-negotiable for any codebase over 5k LOC. Both Bun's default tsconfig and the TypeScript handbook ship with this posture for migrations.

Step 2: add // @ts-check and JSDoc to high-value files

Before renaming a single file, add // @ts-check to the top of your most important .js files and annotate parameters with JSDoc. You get the type-checker without the build change. Some teams (covered in dev.to's "TypeScript Might Not Be Your God" case study) stop here and ship JSDoc-typed JavaScript forever. That is a legitimate end state for small libraries.

Step 3: rename file by file, lowest-blast-radius first

Start with leaf utilities (date formatters, validators, constants) and work up the dependency graph. Airbnb's ts-migrate tool, still maintained in 2026, automates the rename, fixes obvious type errors, and inserts @ts-expect-error comments where it cannot infer a type. The Airbnb team reported converting projects of more than 50,000 lines of code in a single day with ts-migrate plus a senior engineer cleaning up afterward.

In 2026, the more common workflow is: point Claude Code or Cursor at a directory, ask it to migrate one file at a time with tests passing, review each PR, and merge. This is what compresses the engineer-week count.

Step 4: ratchet --strict one flag at a time

Once most of the codebase is .ts, do not flip "strict": true on a Friday. Turn on noImplicitAny first, fix or // @ts-ignore the errors, ship. Then strictNullChecks, then strictFunctionTypes, and so on. The dev.to case study "How We Migrated 200K Lines from JS to Strict TypeScript" walks through exactly this ratchet over six months.

A quiet win in 2026: ts-reset, the Matt Pocock library that fixes TypeScript's permissive built-in types (like JSON.parse returning any). Adding it to your tsconfig early forces better discipline as you migrate.

Step 5: pick a runtime that does not fight you

If you are on Node 20+, "moduleResolution": "NodeNext" is the sane default, but it forces you to write .js extensions in your .ts import statements. Half the migrations we have seen lose a week to this. Bun's runtime, which executes TypeScript natively without a build step, sidesteps the issue entirely. So does Vite for frontends and tsx for Node scripts. Decide your runtime story before you flip strict.

Where teams overspend

Three line items eat the budget every time:

Test migration. Jest's TypeScript support is fine, but the type-of-mock dance (jest.MockedFunction and friends) is genuinely painful. Many teams use the migration as cover to switch to Vitest, which has better TypeScript ergonomics out of the box. Budget 15 to 25% of the total migration cost for tests if you switch frameworks.

Third-party type definitions. Half your node_modules will have @types/foo packages with subtly wrong types. The other half will be untyped. You will spend real time writing declare module shims. Budget one mid-tier engineer-week per 10k LOC just for this.

ESM and CommonJS interop. If your codebase is still CJS and you are also moving to ESM, do not do both at once. The combination of "type": "module", .js extensions in imports, and TypeScript's resolution modes is the single biggest source of mid-migration burnout. Pick one cutover at a time.

The same trade-off shows up in adjacent migrations; we wrote about it in our piece on the cost to add user authentication, where teams routinely overspend on the auth library swap and underspend on the migration plan.

When to hire vs do it in-house

A 10k-LOC migration is a fine internship project for a strong mid-level engineer. A 100k-LOC migration with strict mode and a test framework swap is senior-or-better work. Anything past 500k LOC needs a lead, period, because the most consequential decisions (tsconfig posture, runtime choice, which files get strict-mode-first) compound over months.

The honest comparison of approaches:

Approach	Cost (100k LOC)	Timeline	Pros	Cons
Existing team, manual	$0 cash, 18 to 30 eng-weeks of opportunity cost	4 to 8 months calendar	Deep context, no onboarding	Feature work freezes, morale tax
US full-time hire	$35k to $55k for the migration window	4+ weeks to hire + 3 months to ship	Permanent capacity	Slow to start, no off-ramp
Dev agency (US/EU)	$40k to $90k fixed bid	6 to 10 weeks	Predictable scope	Often loses to scope creep on edge cases
Toptal	$20k to $40k at $80 to $150/hr	2 weeks to staff + 8 to 12 weeks to ship	Vetted seniors	Monthly commitments, slower replacement
Cadence	$9,000 to $18,000 at the senior tier	48-hour trial, then 6 to 12 weeks	Every engineer is AI-native by default, weekly billing, replace any week	Less suited to enterprise procurement

The Cadence-specific note worth making: every engineer on the platform is AI-native by baseline, vetted on Cursor, Claude Code, and Copilot fluency before they unlock bookings. That matters here because the 3-4x cost compression on TypeScript migration is entirely contingent on the engineer driving the AI tooling well. A senior engineer who cannot prompt Claude Code to migrate one file with tests passing is paying full manual price.

If you want to compare the migration spend against other build vs buy decisions, our breakdown of the cost to build an AI agent that automates workflows uses the same weekly tier framing.

How to reduce migration cost without cutting corners

Five moves that consistently take 30 to 50% out of the bill:

• Use AI-assisted file-by-file migration. Claude Code, Cursor, or Copilot Workspace, with a human reviewing every PR. This is the single biggest lever in 2026.
• Freeze refactors during migration. Sentry's most expensive lesson. Do the migration, then refactor.
• Skip the strict big-bang. Ratchet noImplicitAny, strictNullChecks, etc. one at a time, ship between each.
• Migrate tests last, or use the migration as cover for a Jest to Vitest swap, but pick one.
• Adopt ts-reset early. Cheaper to write strict types from the start than to soften and re-tighten later.

For a quick honest grade on whether your migration plan is right-sized, run your stack through ship-or-skip before you start. It is faster than scoping out the work yourself.

The fastest path from JavaScript to TypeScript in 2026

If you are starting today, here is the three-step recommendation:

1. Turn on allowJs, checkJs, and a non-strict tsconfig this week. Zero conversion, full type-checker visibility into your JS.
2. Migrate leaf files with Claude Code or Cursor, one PR per file, senior reviewer. Land 5 to 20 files a week depending on complexity.
3. If you do not already have a senior engineer who can drive AI tooling well, book one. A Cadence senior at $1,500/week with a 48-hour free trial is the lowest-risk way to test whether AI-assisted migration actually compresses your timeline before committing months of payroll. See what your migration would cost on Cadence.

The compounding return on TypeScript is real (Airbnb's postmortem found 38% of their bugs were preventable with TypeScript), but only if the migration actually finishes. Most do not, because teams underestimate the strict ratchet and overestimate their ability to do it during feature work. Plan for both.

If you want to ballpark the migration before scoping headcount, run the numbers against your codebase size and engineer rate. Most teams are surprised by how much the AI-assisted column moves their math.

FAQ

How long does a JavaScript to TypeScript migration take?

For most products: 1 to 2 weeks for 10k LOC, 6 to 12 weeks for 100k LOC, and 1 to 2 quarters for 500k LOC, when using AI-assisted file-by-file migration with a senior engineer reviewing PRs. Manual migrations run 3-4x longer.

Can I migrate gradually or do I need a big bang?

Always migrate gradually. Set allowJs: true in tsconfig.json so JS and TS files coexist, then convert file by file. Stripe is the rare exception: they merged 3.7M LOC in a single PR, but they had spent months preparing tooling first. Do not copy that pattern unless you have their engineering bench.

Should I use ts-migrate or Claude Code?

Both. ts-migrate (Airbnb's tool, still maintained) handles the mechanical rename and inserts @ts-expect-error comments. Claude Code or Cursor is better for the type-inference cleanup that follows. The 2026 workflow is: ts-migrate for the bulk pass, then AI agent for the per-file polish, then human review.

Is TypeScript 7.0 worth waiting for?

It is already shipped. TypeScript 7.0 (Project Corsa, the Go-based native compiler) released January 15, 2026, with up to 10x faster compile times. If your CI typecheck is the bottleneck, upgrading is a same-day win. The migration patterns above all still apply.

What is the most common migration pitfall?

Trying to refactor the codebase during the migration. The Sentry team called this their hardest-won lesson. Convert types first, refactor patterns later, ship between every strict-flag flip. Migration plus refactor plus framework upgrade equals a project that never lands.