Engineering Practitioner Brief / 18 May 2026
Framework Migration Cost
A framework migration is unusual among tech debt categories because the deadline is set by someone else. The framework maintainer publishes an end-of-life date, dependent libraries follow it, hosting providers eventually deprecate the runtime, and the security team finally insists. This page collects per-LOC cost ranges for the most common 2026 migrations so teams can size the work before the security ticket arrives.
Per-Migration Cost Reference
The figures below assume a US fully-loaded engineer rate of around $160K per year, equivalent to roughly $85 per engineer-hour. Each row covers the dominant migrations engineering teams face in 2026, with the dollar range scaled to a hypothetical 50,000-LOC codebase. Adjust linearly for your own size.
| Migration | $/LOC | 50K LOC est. | Codemod available | Calendar months |
|---|---|---|---|---|
| React class to hooks | $0.80 to $1.50 | $40K to $75K | Yes (react-codemod) | 3 to 6 |
| Angular.js to Angular 17 | $2.20 to $3.00 | $110K to $150K | Partial (ngUpgrade) | 12 to 18 |
| Rails 4 to Rails 7 | $0.50 to $1.20 | $25K to $60K | Yes (app:update) | 4 to 9 (across 3 majors) |
| .NET Framework 4.8 to .NET 9 | $1.40 to $2.60 | $70K to $130K | Yes (upgrade-assistant) | 6 to 14 |
| Node 12 to Node 22 | $0.30 to $0.90 | $15K to $45K | Partial (npm audit fix) | 2 to 5 |
| Spring Boot 1 to Spring Boot 3 | $1.20 to $2.40 | $60K to $120K | Yes (OpenRewrite recipes) | 5 to 12 |
| Vue 2 to Vue 3 | $1.00 to $1.80 | $50K to $90K | Yes (vue-codemod) | 4 to 8 |
| Python 2 to Python 3 | $0.70 to $2.00 | $35K to $100K | Yes (2to3, Bowler) | 4 to 12 |
React Class to Hooks
React 16.8 (February 2019) introduced hooks. React 19 (2024) made class components legacy but did not remove them. The economic argument for migration is no longer the deprecation deadline; it is the velocity of the rest of the ecosystem. Libraries like TanStack Query, React Hook Form, and Zustand assume hooks-first usage. Maintaining a class-component app in 2026 means writing adapter wrappers for every modern library.
The mechanical part of the migration is well-supported by the official react-codemodcollection: lifecycle methods to useEffect, this.state to useState, this.context to useContext. The codemod handles 70 to 85 percent of class components correctly. The remaining 15 to 30 percent are usually components with intricate lifecycle interactions (componentWillReceiveProps doing data fetching, for example) that map to multiple useEffects with careful dependency arrays. These cases benefit from manual rewriting and require new tests.
Test-rewrite cost is the underestimated part. Tests written against Enzyme's shallow-render assume class internals. Migrating to React Testing Library is a parallel project of similar size to the component migration. Plan for that.
Angular.js to Angular 17 (or 18+)
The hardest mainstream migration of 2026. Angular.js (1.x) reached end-of-life on 31 December 2021. Angular (2+) shares essentially no API with it: different language (TypeScript not JavaScript), different module system (ES modules not AngularJS modules), different change-detection strategy, different routing, different forms, different dependency injection. The official ngUpgrade hybrid pattern is the only realistic way to ship incrementally, but it doubles the bundle size for the duration of the migration and adds runtime complexity.
Reference cases (the Angular team's own blog posts on Google's internal migrations) suggest 12 to 18 months for a 50K-line app with a dedicated 4 to 6 engineer team. Larger apps scale roughly linearly. Smaller apps are often better off as a clean-room rewrite because the ngUpgrade overhead is fixed.
The strongest economic argument here is hiring: Angular.js skills have evaporated from the senior market. Job postings using Angular.js receive a small fraction of the applicants a modern Angular posting does, and the applicants who do apply ask for higher rates as a maintenance-only premium.
Rails 4 to Rails 7 (or 8)
Rails encourages a chained-upgrade approach: each major version supports upgrade from the immediately preceding major version (with a sometimes-supported 2-version-back fallback). To go from Rails 4 to Rails 7, the conventional path is 4.2 to 5.0 to 5.2 to 6.0 to 6.1 to 7.0, with the heaviest work falling at the 4-to-5 step (autoloader changes, parameter wrapping changes) and the 6-to-7 step (Zeitwerk autoloader becomes default, asset pipeline changes).
Each major includes the rails app:update generator that diffs the standard config against the new defaults. Combined with the deprecation warnings logged during a full test suite run, the mechanical part of each step is well-understood. The expensive parts are usually gem upgrades that follow the Rails version constraint (PaperTrail, Sidekiq, Devise often need their own major-version bumps), and Ruby version upgrades that gate the Rails version (Ruby 2.x to 3.3).
See Ruby Rails legacy cost for the per-version breakdown.
.NET Framework to .NET 9
Microsoft ended new feature development for .NET Framework at version 4.8 in 2019. Security patches continue, but the .NET 9 platform (released November 2024) is the supported path. The .NET Framework to .NET 9 migration is structurally a port to a different runtime, not a version upgrade. APIs that exist in .NET Framework only (System.Web, WebForms, WCF server, AppDomains, remoting) require replacement or removal.
The .NET Upgrade Assistant automates the project-file conversion, the namespace updates, and flags the API replacements needed. It does not write the new code for retired APIs. WebForms apps usually rewrite as Blazor or ASP.NET Core MVC. WCF servers usually move to gRPC or REST. See .NET Framework legacy cost for the full breakdown.
Node 12 to Node 22
Each Node major LTS reaches end-of-life around 30 months after release. Node 12 reached end-of-life April 2022, Node 14 reached end-of-life April 2023, Node 16 reached end-of-life September 2023. Teams still on Node 12 in 2026 are running unpatched runtime with all the CVE risk that implies. The Node 22 LTS (October 2024) is the supported destination for most teams in 2026.
The Node runtime itself is unusually backward-compatible: most v12 code runs unchanged on v22. The cost shows up in transitive dependencies, where library versions compatible with Node 12 are also unmaintained and require their own upgrades. The dependency tree update is usually the bulk of the work. JavaScript and Node legacy cost covers the dependency arithmetic.
Deprecation-Pressure Timeline (2026 view)
A practical decision aid: how many years past end-of-life can a framework realistically run before the forced-action moment? Patterns from observed enterprise practice:
- 0 to 1 year past EOL: security team unhappy, hiring still possible, library ecosystem still publishing compatible versions. Most teams ignore this.
- 1 to 3 years past EOL: CVE backlog grows, hosting providers start charging premiums for legacy runtimes (AWS Extended Support, Azure ESU). Hiring premium of 20 to 40 percent for engineers willing to work on the stack.
- 3 to 5 years past EOL: library ecosystem actively drops support, build tooling stops working without pinned ancient versions of itself. CVE remediation requires backporting patches manually. Hiring premium of 50 to 100 percent. Most teams are forced to act in this window.
- 5+ years past EOL: nobody starts new projects on the stack, the application becomes a maintenance island. Migration cost has roughly doubled from what it would have been at year 2, because the gap to current versions is now larger and the available expertise has shrunk further. The COBOL pattern. See COBOL mainframe debt cost for the extreme case.
Related Reading
- Legacy code refactoring cost
- Dependency debt cost
- Java Spring legacy cost
- Python and Django legacy cost
- Strangler-fig migration cost
Frequently Asked Questions
How much does a framework migration cost per LOC?
Roughly $0.50 to $3.00 per line of code at US fully-loaded engineer rates, depending on how much of the work codemods can automate. Major-version Rails upgrades land at the low end (much is mechanical). Angular.js to Angular 17 lands at the high end (effectively a rewrite). React class-to-hooks lands in the middle ($0.80 to $1.50 per LOC) because codemods exist but tests need rewriting.
Why migrate at all if everything works?
Two reasons that always apply: security patches stop after end-of-life, and hiring becomes harder as the framework ages. Two reasons that sometimes apply: hosting providers deprecate the older runtime, and dependency libraries drop support so the rest of the stack effectively forces the upgrade.
How long does an Angular.js to Angular 17 migration take?
For a 50,000-line Angular.js app, plan 12 to 18 months of effective engineer-team time. Angular.js (1.x) and Angular (2+) share almost no API; the migration is closer to a rewrite than an upgrade. Most teams use the ngUpgrade hybrid pattern to ship incrementally rather than freezing development.
Are codemods worth using?
Yes, where they exist. React's react-codemod, Vue's vue-codemod, jscodeshift, ts-morph, Spring Boot's OpenRewrite recipes, Rails's app:update generators, and the .NET upgrade assistant collectively save 30 to 70 percent of the mechanical work on their respective migrations. They do not replace the architectural and testing work, but they remove a category of typo-driven defects.
Can I skip a major version?
Usually no. Most frameworks support upgrades only from the immediately preceding major version (sometimes one further back). To go from Rails 4 to Rails 7, the standard sequence is 4 to 5, 5 to 6, 6 to 7. Each step has its own deprecation list. Skipping versions doubles the work because the deprecation messages from the missing version no longer fire.
What is the cost of NOT migrating?
Compound. After 2 to 3 years past end-of-life, security patches stop and the security-debt portion of total tech debt grows roughly 30 percent per year. Hiring becomes 2x to 5x harder because senior engineers refuse to work on dead-end stacks. New library releases drop support for the old framework, leaving the team patching libraries themselves or pinning forever.