How to switch proxy providers without downtime

To switch proxy providers without downtime, put a thin configuration layer between your jobs and any single provider, translate your endpoints, credentials, session and targeting parameters into the new provider's equivalents, and run both providers in parallel on a controlled share of production traffic. Cut over only when the new provider matches the incumbent on validated success rate, block rate, latency and cost per successful request for each target that matters, and keep the old contract live until rollback is no longer plausible.

Most migrations that go wrong do so for dull reasons: a credential hard-coded in a forgotten cron job, a partner that allowlisted the old egress addresses, or a sticky session that silently lasts ten minutes instead of thirty. The steps below are ordered to surface those early.

Start with an inventory of what you actually run

You cannot map what you have not found, and teams that switch proxy providers without incident almost always start here. Before talking to any vendor, build a list of every place proxy traffic originates and every assumption it makes about the provider. Search your repositories, notebooks, infrastructure code and secrets manager for the incumbent's gateway hostname and for the environment variable names that hold its credentials. Check egress firewall rules too, since they often name the provider's gateway addresses.

For each workload, record:

• Endpoints. Hostnames and ports per pool and per protocol. Some providers use one gateway for everything; others use a different host or port per pool, country or session mode.
• Credential formats. Username and password, IP allowlist entries, or both. Note which teams share credentials and which have their own sub-users.
• Session semantics. Rotating per request or sticky; how a session is requested; the maximum sticky duration; and what happens when the exit address disappears mid-session (a silent switch to a new address, or an error).
• Geo and ASN targeting. Country, region, city, ASN or carrier targeting in use, and how precise each actually needs to be.
• Allowlists at third parties. Partners, data vendors or client APIs that accept requests only from your current static egress addresses. These have the longest lead times in any migration.
• Protocol. HTTP CONNECT or SOCKS5, and whether DNS is resolved locally or at the proxy.
• Concurrency. Peak simultaneous connections per job and any per-account limits you currently hit.
• Usage by pool. Gigabytes per month on residential and mobile, address counts on ISP and datacenter, split by team or project. Billing exports are the quickest source.

The inventory usually turns up at least one workload nobody remembered. Better to find it now than when its credentials stop working.

Build a parameter-translation map

Every provider expresses the same concepts differently. Targeting might live in the username, the hostname or the port; sessions might be keyed by an identifier you choose or one the provider issues. Write the mapping down as a table before anyone touches code, and have the new provider confirm each row in writing.

The last row matters more than it looks. If one provider meters only response bodies and the other meters both directions including headers, identical traffic produces different invoices. Our guide to proxy pricing per GB and per IP covers where those differences hide.

Put a thin abstraction in front of any provider

If the proxy URL is assembled inside job code, every provider change is a code change in every job, and the next time you need to switch proxy providers you pay the same cost again. Move it out. The simplest version is one environment variable per pool, read at startup:

export PROXY_URL="http://USERNAME:[email protected]:PORT"

Larger estates benefit from a small proxy configuration service or library that takes a request for a pool, a country and a session key, and returns a connection string for whichever provider is currently assigned. Provider-specific syntax lives in exactly one place, and switching is a configuration change that can be made per job, per team or per percentage of traffic.

The same layer is where the parallel run is controlled. A deterministic assignment keeps each job on one provider across restarts, which matters for anything with state:

import hashlib
import os

PROXY_URLS = {
    "incumbent": os.environ["PROXY_URL_INCUMBENT"],
    "candidate": os.environ["PROXY_URL_CANDIDATE"],
}
CANDIDATE_SHARE = float(os.environ.get("CANDIDATE_SHARE", "0"))


def provider_for(job_id: str) -> str:
    bucket = int(hashlib.sha256(job_id.encode()).hexdigest(), 16) % 10_000
    return "candidate" if bucket < CANDIDATE_SHARE * 10_000 else "incumbent"


def proxy_url_for(job_id: str) -> tuple[str, str]:
    provider = provider_for(job_id)
    return provider, PROXY_URLS[provider]

Return the provider name alongside the URL and attach it to every log line and metric. Without that label, the parallel run produces no comparison at all.

Run both providers in parallel

A parallel run answers one question: on your targets, at your volumes, does the new provider perform at least as well as the one you have? Synthetic tests before purchase are useful for shortlisting, and our guide on how to benchmark proxy providers covers designing a fair one, but only production traffic shows how a provider behaves against the exact mix of sites, times and concurrency you run.

Percentage-based splitting

For stateless fetches through rotating addresses, route a random share of requests to the new provider. Start small, typically a few percent, and raise the share in stages as the numbers hold. Randomizing per request means both providers see the same targets at the same times, which removes most time-of-day and target-mix bias.

Per-job splitting

Anything with state, such as logins, carts, paginated sessions or flows that must keep one address, has to stay on one provider for its whole life. Assign whole jobs, targets or customers by hashing a stable identifier, as in the example above. Check that the candidate is not given only the easy targets: if the hard ones all stay on the incumbent, the comparison flatters the newcomer.

Whichever method you use, make sure the new provider's session behavior matches what the job expects. Our explainer on rotating vs sticky proxies covers the failure modes when it does not.

Which metrics to compare during the parallel run

Compare per target, not in aggregate. A provider can win overall while failing on the one site that matters most.

• Success rate by target. Count a request as successful only when the response contains the content you needed. An HTTP 200 carrying a challenge page or an empty template is a failure.
• Block and captcha rate. 403 and 429 responses, challenge pages and soft blocks such as degraded or localized-wrongly content. Handling 403 and 429 errors explains how to classify them.
• Latency at p50 and p95. Time to the complete response, per target. The p95 is what makes jobs miss their windows.
• Cost per successful request. Attributable spend divided by validated successes. For per-GB pools, include retry and failed-request bytes; for per-address pools, divide the monthly cost by successes carried.
• Geo accuracy. For a sample of requests, check the exit address against an independent geolocation source and confirm what the target itself shows: currency, language, local results.
• Error classes. Connection timeouts, gateway errors and authentication failures are provider problems; target blocks are partly yours. Keep them apart.

Cutover criteria and rollback

Write the cutover criteria down before the parallel run starts, so the decision is not argued from whichever numbers look best afterward. A workable set:

1. For every critical target, the new provider's validated success rate is equal or better within a margin you set in advance, measured on enough requests for the difference to be meaningful.
2. Block rate, p95 latency and cost per successful request are within agreed tolerances.
3. Geo accuracy on sampled requests meets the workload's needs.
4. The run has covered a full business cycle, including your weekly peaks and any month-end jobs.
5. No unexplained error class appears on the new provider.

Then ramp in stages, for example to a quarter, a half and all traffic, holding at each stage long enough to see a peak.

Rollback must be a single configuration change. That means the incumbent's credentials stay valid, its allowlist entries stay in place, and its balance or plan stays funded until the rollback window closes. Rehearse the rollback once during the parallel run by moving a job back and forth; a path that has never been exercised is not a rollback plan. Where possible, automate the trigger: if validated success for a critical target drops below a threshold for a sustained period, the configuration layer returns that target to the incumbent and pages someone.

When to overlap and end the old contract

Work backward from the incumbent's renewal date. Note any notice period, auto-renewal clause, minimum commitment, and whether prepaid gigabytes or balances expire. The parallel run should begin early enough that cutover, plus one billing cycle of rollback cover, finishes before the notice deadline.

Third-party allowlists usually set the true start date. If a partner needs two weeks to add new static egress addresses, request them before the parallel run, not at cutover. Ask for the new addresses to be added alongside the old ones rather than replacing them, so both paths work during the overlap.

After full cutover, reduce the incumbent to the smallest plan that keeps rollback possible, then end it at the renewal date. Some teams choose instead to keep it permanently on a small share of traffic as a warm standby. If the reason you want to switch proxy providers is concern about how the incumbent sources its network, do not keep it as a standby; the proxy provider shutdown playbook explains why a network built on questionable supply can disappear overnight.

Migration checklist

Copy this into your migration ticket.

• Every workload, repository, notebook and cron job that uses proxies is listed with its owner
• Credentials are stored in a secrets manager, not in code or job definitions
• Endpoints, credential formats, session modes and sticky durations are recorded per workload
• Geo and ASN targeting requirements are recorded with the precision actually needed
• Third parties that allowlist your egress addresses are listed with their lead times
• Protocol and DNS resolution mode are recorded per workload
• Peak concurrency and monthly usage per pool are recorded
• The parameter-translation map is confirmed in writing by the new provider
• Jobs read proxy settings from configuration, and every request is labeled with its provider
• Cutover criteria and sample sizes are written down before the parallel run starts
• The parallel run covers a full business cycle and every critical target
• Rollback has been rehearsed as a configuration change
• The incumbent's renewal date, notice period and balance expiry are on the calendar
• The new provider has passed your proxy provider due diligence, including evidence of how its addresses are sourced

Switching to ProxyForge

We run migrations as a concierge process. An engineer maps your current setup with you, we mirror your endpoint structure, session syntax and authentication format on our gateway so jobs need as little change as possible, and you run both providers in parallel and compare on your own dashboards. You shift the rest when the numbers justify it. There is no need to cancel your incumbent before starting, and the parallel run is billed at our published rates.

If sourcing is part of the reason for the move, our sourcing policy names the channels we permit and prohibit and how they are audited. The migration page describes the process in more detail, and you can contact us to start the mapping.