A Manifest V3 migration costs roughly $1k to $3k for a simple extension, $3k to $8k for one with real background logic and moderate permissions, and $8k to $15k or more for anything that leaned on blocking webRequest or ran remote code. The single biggest cost driver is not the manifest file — it is whether V3's runtime changes force a redesign of how your extension holds state and intercepts requests, because those are rewrites, not edits.
This is the buyer's companion to our technical Manifest V2 to V3 migration guide. That guide covers what breaks and how to fix it; this one is about what it costs, how long it takes, and whether to do it in-house or hand it to a Chrome extension team. If you already know V3 broke your extension and just want to know what the fix is worth, you are in the right place.
Migration cost by extension complexity
The honest ranges below are for migrating an existing, working V2 extension to V3 — not building from scratch. They assume the code is readable and the original intent is recoverable. Undocumented, obfuscated, or abandoned codebases sit at the top of each band because half the job becomes figuring out what the extension was allowed to do before you can safely change it.
| Extension type | What it involves | Migration cost | Timeline |
|---|---|---|---|
| Simple | Popup or options UI, a short permission list, state in the browser, no network interception | from ~$1k–$3k | 2–5 days |
| Medium | Background logic, timers, message passing, content scripts on a few sites, moderate permissions | ~$3k–$8k | 1–2 weeks |
| Complex | Blocking webRequest, remote/hosted code, multi-site content scripts, a back end or licence check | ~$8k–$15k+ | 3–6 weeks |
Manifest V3 migration cost and timeline by extension type (2026 ranges).
What actually drives the migration cost
The manifest edits themselves are cheap and fast — bumping the version, collapsing browser_action into action, moving host permissions. If that were the whole job, every migration would be a simple one. The cost lives in four changes V3 forces, and how many of them your extension trips over decides which band you land in.
Background page to service worker
V2's background page stayed alive and remembered things. V3's service worker is ephemeral — Chrome kills it after about thirty seconds idle. Every counter, cache, login flag, or timer your extension kept in memory has to move to chrome.storage, and every read has to assume a cold start. This is the change that catches the most extensions, because the old code appears to work until the worker sleeps mid-task. The more state your background context held, the more of this rewrite you pay for.
Blocking webRequest to declarativeNetRequest
This is the expensive one. If your extension inspected or modified network requests in its own JavaScript — ad blockers, header rewriters, request filters — V3 removes that power and replaces it with declarativeNetRequest, where you declare static or dynamic rules up front and Chrome enforces them. Not all interception logic maps cleanly onto the declarative model, so this is not a port; it is a redesign, and it needs a feasibility check before anyone quotes a date. An extension whose entire reason to exist was blocking webRequest is always a complex migration.
Remote code removal
V3 bans remotely hosted code — you can no longer fetch JavaScript from a server and run it. Anything that loaded logic at runtime has to ship inside the package, and string-based script injection has to be rewritten to inject functions or files instead. If your extension pulled in a third-party script or updated its own logic over the air, that pattern is gone and has to be re-architected.
Re-review and permissions
Every migration ends with a Web Store resubmission that is reviewed from scratch. The upside: declarativeNetRequest often lets you drop the broad host access V2 needed, so a well-scoped V3 version can clear review faster than the original. The cost: any new or scary-looking permission can hold your submission for manual review, and that queue is outside your control.
DIY vs hiring it out
A simple migration is a reasonable thing to do in-house if you have a developer who knows the extension and the deadline is not tight; if you don't, hiring a specialist extension developer is the alternative. The calculus changes fast once blocking webRequest or remote code is involved, because those are the parts where an inexperienced migration ships a silent regression that your users find before you do.
| DIY / in-house | Hire a specialist | |
|---|---|---|
| Best for | Simple extensions, a dev who wrote the original, no hard deadline | Complex migrations, webRequest rewrites, or a broken extension already pulled from the store |
| Out-of-pocket cost | Internal time only | from ~$1k for simple, $8k+ for complex |
| Main risk | Service-worker state bugs that pass testing and fail in production | Coordination overhead and scoping an unfamiliar codebase |
| Re-review handling | You learn the current review bar as you go | Done it recently, keeps the permission list narrow to clear review faster |
| Timeline certainty | Open-ended — the hard parts surface late | Scoped up front, with the webRequest feasibility checked first |
Doing the migration in-house versus hiring a specialist.
Why hand a V3 migration to Duskel
We are not a marketplace of freelancers guessing at someone else's code. Duskel is a studio that ships and maintains its own production software, including Chrome extensions, so a V3 migration is a thing we have actually done under real Web Store review rather than read about. That matters most on the two parts that sink DIY migrations: forcing the failure by killing the worker between every action to prove the state migration is real, and knowing before we quote whether your webRequest logic even fits the declarative model.
Because we own our own extensions, we keep the permission list as narrow as the new APIs allow — which is both good security and the thing that gets your resubmission through review faster. We will audit what your extension does, tell you honestly which complexity band it falls in, and give you a fixed scope instead of an open-ended hourly bill. If the answer is "this is a simple one, do it in-house," we will tell you that too.
If you want it scoped, tell us what your extension does and we will come back with a band, a number, and a timeline — or see how we work on Chrome extensions first.