How to Consolidate Several Proxy Subscriptions Into One

Consolidation is not automatically correct. It is correct when the plans overlap in what they do, and wrong when they overlap only in what they are called. Three questions decide it.

Do the workloads want the same product? Rotating datacenter addresses, static addresses held for logins, and a managed scraping API are three different products that happen to be sold by overlapping vendors. Merging plans that serve different products is not consolidation, it is breaking things to reduce the number of invoices.

Is the combined peak smaller than the sum of the purchased capacity? It usually is, sometimes dramatically, and that gap is the entire financial case. If your four plans genuinely run at their ceilings simultaneously, consolidation saves you an invoice and nothing else.

Can you survive a single point of failure? Four vendors is redundancy, badly paid for but real. One vendor is a dependency. If an outage stops revenue rather than delaying a report, keep a second vendor deliberately and size it small. Our notes on proxy failover and redundancy cover what a useful standby actually looks like.

If the answers are yes, smaller, and yes, carry on. If the third answer is no, your target is two plans rather than one, and everything below still applies.

You cannot consolidate what you cannot list, and the list is always longer than anyone expects. Build a single table with one row per subscription and do not skip a column because it is annoying to find.

Two rows will surprise you. There is nearly always a plan with no traffic at all, and there is nearly always a workload running on credentials nobody can attribute. Chase both down before you go further, because the zombie plan is free money and the orphan workload is the thing that breaks during cutover.

Freeze new purchases while you do this. A consolidation that runs for six weeks while two more plans get bought is not a consolidation.

Sort every workload into one of these buckets before you pick a survivor plan.

The three "no" rows are the ones people get wrong. An address holding a logged-in account is an identity, and identities do not rotate. Merging that workload into a rotating plan does not save money, it destroys account history that took months to build. Keep those subscriptions, shrink them to the number of addresses actually in use, and consolidate everything else around them.

The last row deserves attention too. If one of your plans carries a minimum spend commitment, migrating traffic off it does not reduce the bill, it just means you pay the minimum for nothing. Read the commitment before the cutover plan, not after.

Here is the arithmetic that makes or breaks the exercise.

Take a realistic starting position: three concurrency-priced plans plus one per-address plan.

• Plan A: 100 threads at $75 a month
• Plan B: 100 threads at $75 a month
• Plan C: 250 threads at $140 a month
• Plan D: 20 static addresses for account work

Purchased concurrency across A, B and C is 450 threads, for $290 a month. Now measure what those three actually use. Instrument the client side for two to four weeks and record concurrent requests in flight per minute, then take the 95th percentile per plan. Say it comes back as 40 for A, 30 for B and 180 for C.

Case 1: the peaks coincide. If all three teams run at the same hours, your combined peak is 40 plus 30 plus 180, which is 250 threads. Add headroom of around 30% for growth and for bursts the 95th percentile hides, giving 325. The smallest plan above that is a 500 thread tier at $240 a month. You are replacing $290 of spend with $240, saving $50 a month, or $600 a year, and you have gone from 450 purchased threads to 500.

Case 2: the peaks are staggered. More common, because a nightly batch and an interactive tool do not peak together. Measure the combined series rather than adding the individual peaks, and say the combined 95th percentile comes back at 190. Add 30% and you need 247, which fits a 250 thread tier at $140 a month. Now you are replacing $290 with $140, saving $150 a month, or $1,800 a year.

The difference between those two outcomes is $1,200 a year and it is decided entirely by whether you measured the combined series or added up three separate peaks. Concurrency is shared, not additive. Measure the sum of the series, not the sum of the summaries.

Plan D does not move. Those 20 addresses hold accounts, and the right action there is to check whether all 20 are still in use and shrink the plan to the number that are.

Two sizing cautions. The 95th percentile deliberately ignores your worst minute, so 30% headroom is the minimum, and if your workload has a hard deadline use the 99th percentile instead. And concurrency is not the only ceiling: check the plan's speed cap against the throughput you actually pull, since fair usage ceilings rise with tier and a cheaper tier can be concurrency-adequate and bandwidth-tight. Our explainer on concurrent connections in proxies covers how threads translate into request rate.

You size on threads, you buy on threads, and then the whole thing is decided by something else entirely.

Plans that support whitelist authentication include a fixed number of whitelist slots, and the count scales with tier. On SparkProxy's ladder that is 5 slots on Starter at $75, 10 on Core at $140, 15 on Boost at $240 and 25 on Plus at $440. When four teams each ran their own subscription, each had its own slot allowance. Merge them and every egress address in the company has to fit inside one allowance.

Count them honestly. Four teams with three environments each, production, staging and a developer machine, is twelve egress addresses. Twelve does not fit in the 10 slots of the 250 thread tier, even though 250 threads is exactly what your measurement said you needed. You are pushed to the 500 thread tier at $240 purely by the slot count, and $100 a month of your $150 saving disappears into whitelist entries.

There are two ways out and one of them is free.

Move to credential authentication. Username and password auth has no slot limit, works from ephemeral cloud addresses, and removes the entire problem. This is the right default for anything running in a container, a scheduler or CI, and consolidation is the natural moment to make the switch. Rotate the credentials afterwards, since you will have handed them to more people than before.

Or route through fewer egress addresses. Put each environment behind one NAT gateway and whitelist that. Twelve addresses becomes four, which fits comfortably. This costs a little infrastructure and buys you a cleaner audit story, which some teams want anyway.

Our explainer on IP whitelisting for proxies covers the mechanics of both.

The rule underneath all of this: nothing gets cancelled until something else has been carrying its traffic for two full billing cycles. Overlap is cheap. A day with no working proxies is not.

1. Freeze and inventory. No new subscriptions until this is finished. Build the table from section 2.
2. Measure for two to four weeks. Concurrency in flight, requests per day, bandwidth, and per-workload attribution. You cannot size without this and you cannot verify the cutover without a baseline.
3. Classify every workload using the table in section 3. Anything in a "no" row stays where it is.
4. Choose the survivor and size it to combined peak plus 30%, then check the slot count and the speed ceiling against what you measured.
5. Buy the survivor and run it in parallel. Both old and new live at once. Send a shadow copy of one low-risk workload through the new plan and compare success rates, latency and response bodies, not just status codes.
6. Cut over one workload at a time, lowest risk first. Batch jobs before interactive tools, internal before customer-facing, and never two in the same week. Keep the old credentials configured and reachable so a rollback is a config change rather than a purchase.
7. Watch for two full billing cycles. Block rates and challenge rates drift, and a new exit pool sometimes behaves differently on a specific target only after a few weeks.
8. Then begin the lapse sequence in section 7.
9. Revoke credentials and clear whitelist entries last. Only after logs show zero traffic on the old plan for a full cycle. Revoking early is the classic way to discover an undocumented workload at the worst possible moment.

The overlap in steps 5 to 7 costs you roughly two months of double billing on one plan. Budget for it explicitly and stop treating it as waste: it is the insurance premium on the whole project. Our guide to switching proxy providers without downtime covers the mechanics of a single provider-to-provider move in more detail, and those mechanics apply to each individual cutover here.

Cancelling in the wrong order is how a consolidation turns into a loss. Work in this sequence.

Three specifics worth writing down.

Watch validity windows. Plans that run on a fixed validity, 30 days on SparkProxy's proxy plans for example, do not roll unused capacity forward. Time your final cycle so you are not paying for a window you will not use, and do not top up a plan you intend to drop.

Do not cancel to get a refund. Refund policies on proxy plans are narrow and usually tied to the first days of a subscription, so an unused half-month is very rarely recoverable. Let it run out instead. Our comparison of proxy free trials and refund policies covers what the terms typically say.

Tell the vendor you are consolidating. Not out of courtesy. A vendor facing the loss of three of your four plans will frequently discount the survivor, and consolidation is one of the few moments when your bargaining position is real, because the alternative is already scoped. Our guide to negotiating proxy volume discounts covers how to open that conversation, and monthly versus annual proxy plans covers the term trade you will be offered in response.

The hidden cost of one bill is that nobody knows whose traffic it is. Four invoices were a crude but functioning chargeback system, and consolidation deletes it.

Rebuild attribution deliberately, on day one, not after the first argument about the bill.

Issue per-team credentials rather than sharing one. Separate sub-users give you usage attribution, let you revoke one team without disturbing others, and make credential rotation survivable. Our guide to sub-users and credential rotation covers the setup.

Tag requests at the application layer too. On a managed API, a per-workload label on each request gives you attribution that survives a credential change. On the SparkProxy Scraping API that is the tag parameter, and the X-Credits-Used response header lets each team reconcile its own consumption against the invoice.

Publish usage weekly, not monthly. A team that sees its own consumption every week manages it. A team that sees an allocation on a quarterly finance report argues about it.

Agree the split rule before you need it. Share by measured usage, by seat, or flat, and write it down. The specific rule matters much less than agreeing it while nobody is over budget.

An honest guide names what you are giving up.

Redundancy. One vendor means one outage. If you consolidate, add a deliberate standby: a small plan on a second provider, credentials already in config, tested quarterly. The cost of a minimal standby is far less than the cost of the outage it covers.

Negotiating position, later. Once all traffic sits on one plan, your next renewal is a conversation with someone who knows switching is expensive. Keep the standby partly for this reason, and re-benchmark annually so the alternative stays real.

Blast radius on credentials. One credential set now opens everything. Per-team sub-users and a rotation schedule are not optional after consolidation.

Diversity of exits. Four vendors meant four address pools, and a target that blocked one did not block all. After consolidation a single pool decision affects every workload at once. Watch block rates per workload for the first two months and keep the standby routable.

None of these is a reason not to consolidate. They are the four things to design around while you do it, and they are why the recommendation above is "one primary plus a deliberate standby" rather than literally one subscription. For the broader procurement view, our enterprise proxy procurement checklist covers what to ask before you sign the survivor.