A Manifest V3 migration runs from about $1k for a simple extension to $15k+ for one built on blocking webRequest. Here is what sets the number and when to hire it out.
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.
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 |
Timelines include Web Store re-review. A V3 resubmission is a fresh review, and a changed permission set can trigger manual review that adds days to a couple of weeks with nothing you can do to speed it up. Budget for that gap before any deadline you care about.
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.
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.
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.
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.
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.
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 |
The most expensive path is a half-finished DIY migration that gets published, breaks for a third of users on a cold worker, and then has to be diagnosed and redone under pressure. If the extension earns money or has real users, that risk usually outweighs the fee to have it done once.
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.
A simple extension — popup or options UI, a short permission list, no network interception — is roughly $1k to $3k and a few days of work. One with real background logic and moderate permissions runs about $3k to $8k over one to two weeks. Anything built on blocking webRequest, remote code, or a back end is $8k to $15k or more and three to six weeks, because those are redesigns rather than edits. Every quote also has to absorb a fresh Web Store review.
The manifest edits are cheap. The cost comes from four runtime changes V3 forces: moving state out of the now-ephemeral service worker into storage, rewriting blocking webRequest logic as declarativeNetRequest rules, removing any remotely hosted code, and passing a fresh Web Store review. How many of those your extension trips over decides the price. An extension that only restyles a page barely touches them; an ad blocker built on webRequest hits all four.
A simple migration is a few days. Medium extensions take one to two weeks, and complex ones with a webRequest rewrite take three to six weeks. Add Web Store re-review on top: a V3 resubmission is reviewed from scratch, and a changed permission set can trigger manual review that adds days to a couple of weeks you cannot speed up. Migrate with room before any deadline rather than assuming approval is instant because the extension already existed.
Do a simple migration in-house if you have a developer who knows the extension and no tight deadline. Hire a specialist once blocking webRequest, remote code, or a back end is involved, or if the extension was already pulled from the store — those are the cases where an inexperienced migration ships a silent regression on a cold service worker. The costliest outcome is a half-finished DIY migration that has to be diagnosed and redone under pressure.
A software studio that ships and maintains its own products — KeepChats, Gwora and Cairn — and builds the same way for clients. Founded and led by codewithumar.
Talk to the studio →Send the problem. You get one fixed number and a plan back within a business day.
We build software worth keeping — for clients, and for ourselves.
Founded & led by codewithumar