From $8/GB to $0.65/GB: What Switching Your Scraping Infrastructure Actually Involves

Migrating scraping infrastructure is not a technical project — it’s an accounting project with code attached. This is a phase-by-phase playbook for moving a residential-proxy workload from Bright Data to Thordata, written for the engineer who will do it and the finance lead who will sign off on it. No vendor bashing: Bright Data is an excellent product. It’s just priced for a different buyer than most growing teams.

The migration that prompted this playbook is a familiar one: a data team whose scraping volume grew 40% year over year, whose per-GB bill grew with it, and whose CFO started asking questions that engineering couldn’t answer with a straight face.

First, the Honest Comparison

Bright Data built one of the most complete web data platforms in the industry — enormous IP pool, mature unlocker products, enterprise compliance tooling. The published pricing reflects that positioning: $8/GB pay-as-you-go for residential traffic, with monthly plans from $5–7/GB ($499–$1,999/month) and custom rates above 1 TB. There’s even a deposit match of up to $500 for new accounts.

Thordata’s published residential pricing is a straight volume slider: $2.00/GB at 1 GB, falling to $1.00/GB around 150 GB, $0.73/GB at 1 TB, and $0.65/GB at 5,000 GB. No plan buckets, no sales conversation, minimum purchase of 1 GB.

Here’s what that means at different monthly volumes:

Two caveats keep this comparison honest. First, Bright Data’s rates above 1 TB are negotiated, and large buyers routinely do better than list. Second, Bright Data’s premium buys real things: enterprise agreements, DPAs, SLAs, and a compliance apparatus that matters for regulated industries. If your procurement process requires those documents, that value is real and this article is not for you yet.

For everyone else — self-serve teams with technical staff, where the proxy is a commodity input — the gap at mid volumes is simply too large to ignore.

Phase 1: Inventory (Week 1, No Code Changes)

Every migration that fails skips this phase. Before touching a single endpoint, build a one-page inventory:

• Traffic mix by product. Raw residential, unlocker-style requests, scraper API calls, SERP API calls. Each maps to a different Thordata product with different pricing.
• Traffic mix by target. Which domains consume the most GB? Heavy HTML pages on raw proxies are often cheaper behind a scraper API priced per result — migration is the moment to fix that.
• Session patterns. How long do your sticky sessions need to hold? Thordata supports sticky sessions up to 90 minutes and country/state/city/ASN targeting at no extra cost — confirm your patterns fit.
• Protocol requirements. HTTP/HTTPS/SOCKS5 — all supported, but your custom client code may assume one.

The output of Phase 1 is a workload map that says, concretely, “we send X requests of type A to domain B with session pattern C.” That document is worth more than any vendor’s migration guide, including this one.

Phase 2: Parallel Run (Weeks 2–3)

Run both providers side by side with the same workload, and measure three things: success rate, response latency, and cost per delivered result. Thordata’s free trial credits for its SERP API and Web Scraper API make the API-side comparison free; the residential trial covers the raw-proxy side.

# Dual-write pattern: same job, two providers, compare outcomes
import requests

def fetch_dual(url, config):
    results = {}
    for provider, cfg in config["providers"].items():
        try:
            r = requests.get(
                url,
                proxies=cfg["proxy"],
                timeout=cfg.get("timeout", 30),
            )
            results[provider] = {
                "status": r.status_code,
                "bytes": len(r.content),
                "latency_ms": r.elapsed.microseconds // 1000,
            }
        except Exception as e:
            results[provider] = {"status": "error", "error": str(e)}
    return results

PROVIDERS = {
    "legacy":  {"proxy": {"http": "http://user:pass@brd.superproxy.io:22225"}},
    "thordata": {"proxy": {"http": "http://user:pass@res.thordata.com:18000"}},
}

Success-rate comparison is where opinions die. Thordata publishes a 99.7% success rate on its residential network, but your targets are the only benchmark that matters — an e-commerce team migrating this pattern typically compares block rates on their specific 20 highest-volume domains and makes the call on that data alone.

Phase 3: Traffic Switch (Week 4)

Switch traffic progressively, not flag-day: 10% → 50% → 100% over a week, watching your downstream data quality metrics, not just HTTP status codes. Two platform details make this phase easier than it looks:

The endpoint format is standard. Thordata’s residential proxy uses the familiar gateway:port with username/password (or IP whitelist) auth, and its dashboard includes an endpoint generator for location-pinned endpoints. Most custom proxy-middleware code changes by exactly one line.

The SDK surface covers the API side. For teams using scraper APIs rather than raw proxies, pip install thordata-sdk plus changing an API key and base URL migrates the majority of standard collection jobs. Code samples exist for Python, Node.js, PHP, Go, Java, and C#.

Phase 4: Decommission and Re-forecast (Weeks 5–6)

Only after a clean week at 100% do you cancel the legacy plan. Then redo the budget with the new structure — and this is where the project pays for itself twice: most teams discover during Phase 1 that a chunk of their raw proxy traffic should have been scraper-API traffic all along, billed per delivered result (from ~$0.50 per 1,000 results) instead of per GB of HTML.

A standard migration checklist, for the person tracking this project:

1. Workload inventory complete, traffic mix documented
2. Parallel run ≥ 7 days, success rate within agreed tolerance
3. Cost per delivered result measured on both providers
4. Sticky-session and geo-targeting patterns validated
5. Alerting and dashboards repointed
6. Legacy contract cancelled after clean 100% week
7. New budget forecast signed off by finance

What About the Workloads That Don’t Migrate?

Some workloads genuinely should stay put. If your usage is under ~20 GB/month, the savings are real but small — the migration effort isn’t worth a quarter of engineering time. If you need a signed DPA for a regulated deployment, the enterprise motion is a feature, not overhead. And if your stack depends on a Bright Data-specific product with no equivalent in your evaluation, that’s a legitimate blocker — though it’s worth checking the full catalog first, because most teams find Thordata’s product surface (residential, mobile, ISP, datacenter proxies; Web Scraper API with 120+ pre-built targets; Web Unlocker; Scraping Browser; datasets) covers more than they expected.

One workload category deserves special mention: SERP collection. Teams migrating Google/Bing rank tracking workloads should move them off raw proxies entirely — per-response SERP API pricing (from ~$0.70 per 1,000 responses) plus the managed SERP monitoring solution is the correct architecture regardless of which proxy vendor you keep for everything else. The continuous SERP data crawling service handles scheduling, CAPTCHAs, and structured delivery so the migration of that workload is often a one-sprint project by itself.

The Part Finance Cares About

The published-price gap between the two providers at mid volume is a factor of 3–7×, but the honest projected saving for a typical migration lands lower — usually 50–70% after accounting for the workloads that stay put, the API-product rebalancing, and volume-tier differences. Even at the conservative end, a team spending $2,000/month on residential traffic that migrates to a $0.73/GB equivalent saves enough in one quarter to fund the engineering time the migration consumed.

Run the Phase 2 parallel test with the free trial credits, look at your own success rates and invoices side by side, and let your workload make the argument. That’s how this playbook was written in the first place — and if SERP workloads are part of your mix, start with the SERP monitoring migration path where the payback is fastest. Teams that complete Phase 1 usually find that their SERP-shaped traffic was the single worst fit for per-GB billing — and the single easiest win to move first.