How to Move Antidetect Browser Profiles to a New Tool

Migration is not free and it is not risk-free, so the first question is whether you should do it.

Do not migrate profiles that are currently earning and currently healthy. Let them age out on the old tool while you run its subscription alongside the new one. Two subscriptions for a quarter is usually cheaper than one flagged account, and antidetect tools are cheap relative to the value of an aged, verified identity. Our antidetect browser pricing comparison has the per-profile numbers to put against your own risk.

Do migrate everything that is disposable, dormant or pre-warmup. Those profiles carry no history worth protecting, and moving them first gives you a rehearsal with real data and no downside.

Migrate under duress only with a deadline you control. If the old vendor is shutting down, being acquired or has already cut your access, you are not choosing, you are evacuating. In that case skip the staging and go straight to the export checklist, because exports you cannot run are worth nothing.

One rule worth writing on the wall: export before you cancel. Cloud-stored profiles live on the vendor's infrastructure, and access to them ends with your subscription. Several tools in this category keep data for a grace period after cancellation, several do not, and none of them owe you a second chance. Pull everything while the account is still paid.

A profile is four separate things that people treat as one. Knowing which is which is most of the job.

The fingerprint definition. User agent, screen metrics, WebGL vendor and renderer, canvas and audio noise settings, font list, hardware concurrency, device memory, timezone, locale, WebRTC policy, client hints. This is the vendor's actual product.

The browser storage. Cookies, local storage, session storage, IndexedDB, service worker caches, cache storage. This is where your logged-in state lives.

The operational metadata. Which proxy the profile uses, which platform and account it belongs to, its tags, notes, folder, and who on your team may open it.

The credentials. Saved passwords, autofill, and increasingly passkeys bound to the platform.

Only the second and third survive a move in any useful form, and the second one survives only partially. The thing people get wrong is assuming the session equals the cookies. On a traditional server-rendered site it roughly does. On a modern single-page application, the access token is frequently in local storage and the refresh token in IndexedDB, and the cookie jar contains nothing that logs you in. Export the cookies, import them into a fresh profile, and you land on a login screen while your export file looks perfect.

How to tell which kind of site you are dealing with, before you migrate anything: open the platform in the old profile, open developer tools, and look at Application storage. If clearing local storage logs you out, the session is not in cookies. Do that test per platform, not once. Our note on handling cookies and sessions covers the same distinction from the automation side.

There is no portable profile format between antidetect vendors, in any direction. Each ships its own patched browser core, stores fingerprint values in its own schema, and applies its own noise. A JSON file describing Vendor A's fingerprint cannot be reconstituted inside Vendor B's engine, and a vendor that claimed otherwise would be exporting its competitor's product.

So accept the real constraint: after migration, the platform sees a new device. That is a device-change event, and every risk engine scores it. You cannot prevent it. What you can control is how many other things change at the same time. See what browser fingerprinting is for what is actually being compared, and how antidetect browsers handle fingerprint protection for why the values differ per vendor.

Before you rebuild, record these from the old profile per account, because they are the values you want to reproduce exactly on the new one:

• Platform family, meaning Windows or macOS, and the major OS version string.
• Timezone and locale, both of which must keep agreeing with the exit IP.
• Screen resolution bucket and device pixel ratio.
• Hardware concurrency and device memory.
• Browser major version family, so you do not jump four Chrome majors in one night.
• Language headers, including the full Accept-Language list rather than just the primary.

Match those and the device looks like the same person's new browser install. Miss the timezone and it looks like a different person entirely.

Cookies are the one artifact that genuinely travels, and they are where most migrations quietly lose data. Every tool exports JSON, and no two agree on the schema. These are the fields that break.

A normaliser is twenty lines and saves an evening. This one takes a generic export list and produces a shape most importers accept:

import json, time

def normalise(cookies):
    out = []
    same_site_map = {
        "no_restriction": "None", "none": "None",
        "lax": "Lax", "strict": "Strict",
        "unspecified": None, None: None,
    }
    for c in cookies:
        exp = c.get("expirationDate")
        if exp is not None:
            exp = float(exp)
            if exp > 1e11:          # milliseconds, not seconds
                exp = exp / 1000.0
            if exp < time.time():   # already dead, do not import
                continue
            exp = int(exp)
        out.append({
            "name": c["name"],
            "value": c["value"],
            "domain": c["domain"],
            "path": c.get("path", "/"),
            "secure": bool(c.get("secure")),
            "httpOnly": bool(c.get("httpOnly")),
            "hostOnly": bool(c.get("hostOnly")),
            "sameSite": same_site_map.get(str(c.get("sameSite", "")).lower()),
            "expirationDate": exp,
        })
    return out

with open("old-profile-cookies.json", encoding="utf-8") as fh:
    src = json.load(fh)

print(f"{len(src)} exported, {len(normalise(src))} importable")

Run that count line first, on one profile, before you process two hundred. If a third of your cookies are already expired, that is useful information about how much session you are really carrying across.

Four categories of state that no cookie file contains, roughly in order of how often they ruin a migration.

Local storage. Where most single-page applications keep the access token. Some antidetect tools export it, many do not, and the ones that do often only export it for profiles stored locally rather than in the cloud. If the destination tool cannot import it, that platform needs a fresh login and a fresh device-trust prompt.

IndexedDB. Refresh tokens, offline caches, encrypted client state. Almost never exported by a GUI. If a platform keeps you signed in for months without a visible cookie, this is usually why.

Service workers and cache storage. Rarely session-critical, but a missing service worker changes behaviour on some progressive web apps and can produce a subtly different request pattern on first load.

Device-bound credentials and passkeys. A passkey is bound to the authenticator, and device-bound session credentials tie a session to hardware-held keys. Neither is exportable by design; that is the entire point of them. Any account secured this way will require a full re-authentication on the new tool, and you should plan for the second factor to be demanded. If the account's recovery method is a phone number you no longer control, find that out now rather than at cutover.

The practical consequence is a triage step. For each platform in your estate, classify it as cookie-only, storage-dependent, or hardware-bound. Cookie-only platforms migrate cleanly. Storage-dependent platforms migrate with a login. Hardware-bound platforms migrate with a full identity verification, and those are the ones you schedule individually.

This is the single highest-leverage rule in the whole process.

A risk engine scores change. Migration forces one change you cannot avoid, the device. So do not hand it any others. On the day you move a profile, keep every one of these byte-identical to what the platform saw last week:

• The exit IP. Same address, not the same country, not the same subnet. Same address.
• The timezone and locale on the new profile.
• The account's usual hours of activity.
• The behaviour pattern immediately after login. Do not migrate and then immediately do something the account never does, such as changing a payout method or bulk-editing settings.

The IP requirement is the operationally hard one, and it dictates your proxy setup rather than the other way around. If your account profiles sit behind rotating exits, you have already been changing address constantly and the platform has already priced that in, so match the pool and the country. If they sit on assigned static addresses, keep the exact assignment through the cutover and change it later if at all. If you need the same address held for the length of a session, that is what a sticky session is for, and what a sticky session proxy is covers the mechanics.

Two honest notes on proxies here. First, whatever you were using is the thing to keep, because consistency beats quality during a cutover; upgrading your proxies in the same week you change browsers is exactly the mistake this section exists to prevent. Second, long-lived account work generally wants residential or mobile exits rather than datacenter ones, and SparkProxy is a datacenter-first network with no mobile product, so read mobile or residential proxies for account work before assuming your current setup is right for the accounts you are moving. Our piece on why proxy accounts get suspended covers the signals that actually trigger review.

Build the profile, import the storage, and then check it against a neutral target before you open the platform. Five checks, five minutes.

1. IP and geolocation agree. The address resolves to the country and region you expect, and the profile's timezone matches that region rather than your own.
2. WebRTC does not leak the local address. Confirm the policy is set the way the old profile had it, not merely set to something safe.
3. Client hints match the user agent. A profile claiming Windows in its user agent while its high-entropy client hints say something else is a mismatch a modern platform reads directly.
4. Language headers match the locale. Accept-Language should carry the same ordered list the old profile sent, not a default.
5. The imported cookies are present and unexpired in the new profile's storage view, with the counts matching what your normaliser said should have imported.

Only then open the platform, and open it to a low-stakes page first. A profile page or a settings read, not a checkout and not a payout screen.

Sequence the estate rather than moving it. Four waves, each gating the next.

Wave one, throwaways. Ten to twenty profiles with no value. The point is to find your own broken steps: a cookie field your normaliser missed, a platform that turned out to be storage-dependent, a proxy assignment you did not record. Expect to lose some and do not care.

Wave two, low-value live profiles. Real accounts, small consequences. Move these across several days rather than in one batch, because a platform that sees forty of your accounts change device inside an hour has been handed a cluster to investigate. Spreading the cutover is free and it is the cheapest risk reduction available.

Wave three, mid-value. Only after wave two has been quiet for a full week, including any weekly verification or payout cycle the platform runs. A migration looks fine for six days and then fails at the point where the account next has to prove itself.

Wave four, high-value, individually. One at a time, each on a day chosen around the platform's own calendar. Never during a payout window, a promotion, a verification cycle or any period when the account is about to be looked at by a human. Some profiles in this wave should simply never move, which is a legitimate outcome and the reason the old subscription is still running.

Keep a migration log with the profile, the date, the wave, the exit IP used, and the outcome at seven and thirty days. It turns a stressful project into data you can use the next time a vendor changes its pricing.

Before you commit, put a number on it. The inputs are boring and the total is usually larger than expected.

Those per-profile minutes are illustrative planning figures rather than measurements from any test we ran. Put your own in, because the shape is what matters: a small number of hard profiles dominates the total, and in this example a quarter of the estate consumes more than half the hours.

Against that, two costs people forget. Running both subscriptions during the overlap, which you should budget for a full quarter rather than a month. And the expected loss from the profiles that do not survive, which you can only estimate, but which is the number that should decide whether wave four happens at all. If the honest answer is that moving fifteen high-value accounts risks more than four months of the old subscription costs, then do not move them. Pay two vendors, and let those accounts retire naturally.