Moving your work to a new proxy line without setting off alarms

Running an old mobile line alongside a new one for two extra weeks costs about five dollars here. A SIM is roughly ten a month, so the overlap rounds to a rounding error.

I have watched several people refuse to spend it. Every one then lost most of a Saturday working out which of the things now misbehaving came from the move and which had been broken for a month already.

That is the short version. The long version is an order of operations, and it starts after the decision to leave has already been made. Whether the old line is worth keeping is a different question and I am not relitigating it here. You have decided. The line is going. What follows is only about sequence.

What a group migration looks like from the other side

One account changing address is nothing. Phones hop between wifi and cell all day, people fly, and a login from a new IP on a device the site already recognises does not raise anything on its own.

A set of accounts changing address together is a different object entirely.

If eleven accounts that are supposed to be strangers all appear on the same fresh address inside the same ninety seconds, the site now has a reason to look at them as a group. Until that minute it had no reason to associate them at all. The migration is what supplied the association.

So the naive plan, block out an evening and move everything, is the one guaranteed to produce the signal you were avoiding. The address was never the problem. The synchronised jump is.

What works instead is dull. Move one thing, let it sit, watch it, move the next. Accept up front that this runs over days, because the alternative is deciding halfway through that you are bored and doing the rest in one go.

Start with the list you do not have

Ask anyone to write down every place their proxy endpoint appears. Most cannot. The ones who insist they can are usually missing three.

I now ask before a migration starts, and the answer arrives in instalments: the obvious ones immediately, then a message four hours later beginning “oh, and the”.

Do this part on paper before touching anything live. Places worth checking:

• each antidetect profile individually, because that class of tool rarely has a global setting worth trusting
• the env file on the scraper box, and the second env file on the staging box everyone forgot was still switched on
• a container image built months ago with the endpoint baked in at build time
• anything on a timer: cron, task scheduler, a repo action, a small function somebody deployed once
• your phone, genuinely, because there is usually one app on it nobody remembers configuring
• every outside party holding your old exit address on their side

That last group gets its own section below. It is the one that costs money.

One place, or fourteen

The migration that goes smoothly has the endpoint stored exactly once. One secret store or one environment variable, read at startup by everything that needs it. Changing lines is then editing one value and restarting a few processes.

The migration that goes badly has it in fourteen places and you find the fourteenth in November.

If you are already in the second situation, resist fixing both problems in the same week. Run the move with the scattered config, painfully, using the handwritten list. Centralise afterwards while the whole map is still in your head, since the list you just built is most of that work.

I did it the other way once. Refactored config and changed lines in the same afternoon, something broke, and I had no way to tell which half had done it. Untangling that cost more hours than the refactor was ever going to save.

An order that does not look like an event

The new line goes up first and carries nothing important for a day. A mobile address that has been silent since birth and then suddenly holds eleven logged in accounts reads oddly. Let it do some ordinary browsing.

Then the least valuable thing you own moves. A throwaway account, or a scraper hitting a target with no opinion about you.

Then you wait, two days minimum. This is the step people skip, because nothing visible happens and waiting does not feel like work. What you are watching for is small: a login challenge that never used to appear, an email about a new device, a captcha rate that has quietly doubled, a session dropping earlier than it did last week.

If that first mover is still clean after forty eight hours, take the next small group. Accounts with a genuine relationship can travel together. Accounts that are meant to look unrelated do not move on the same day, and ideally not in the same week.

Two timing details that catch people. If a job deliberately holds one address for hours, let that session end on the old line before the account moves, because an IP changing underneath a logged in session is its own separate failure and stacking it on a migration means you will never learn which one bit you. And if anything drives rotation on a timer or through a rotation API, repoint the scheduler in the same step, or you end up with a webhook receiver still listening for events from a line you no longer use.

The registrations sitting on somebody else’s side

Where you authenticate by registering your address rather than sending a username and password, there is nothing in your code to change when you move. That is exactly why it gets missed. The config file is correct. It stays correct. The far end simply stops recognising where you are arriving from.

Go through everyone holding your old exit address: an API key bound to an IP, a partner endpoint that only answers requests from an address they added for you nine months ago, a client firewall rule, an internal allow list on a box you barely think about.

These fail in the worst available way, which is silently. Many of them do not return an auth error. They return an empty list, or a 200 with nothing useful inside it, and your job keeps running on schedule and writing zero rows for a fortnight.

Register the new address with all of them before cutting over. Some take a week to action the request and a few want an email from a human being.

Why the overlap is the cheapest thing you will ever buy

Keep the old line paid and alive through the entire move, and well past the point where you believe it is finished.

With both lines up you have a control. Something looks wrong, you point that one thing back at the old endpoint for an hour, and you find out whether the migration caused it. Without that, every problem for the next month is a suspect and none of them can ever be cleared.

Five dollars for a fortnight of certainty is the best price on anything in this business, and it is still the first line item people cut. I have never regretted paying it. I have regretted skipping it, which is the next section.

The two things that break in week three

Anything on a slow schedule. You migrate on a Tuesday, everything looks healthy by Thursday, and the weekly job does not fire until Sunday, by which point the migration is mentally closed and nobody is watching. A monthly reconciliation is worse.

Before you start, find the longest interval any of your jobs runs on. That number is how long the migration actually lasts, regardless of how quickly the visible parts moved.

The other one is the third party group again, failing without a noise.

Confirm it, from the machine that will do the work

Verify from the box that runs the job, through the configured path, at the point where it matters. Not from your laptop, and not from a browser tab you had open. Testing from the wrong place is a whole failure mode of its own and deserves its own write up.

Then check the direction almost nobody checks: the old line’s byte counter. If it is still moving traffic three days after the cutover, something is still pointed at it. That counter is more honest than any audit of your own config, because it does not depend on you having remembered anything.

The mistake my overlap hid

I moved my own price monitoring off a line I was retiring. Inventory written, every config updated, verified from the box, old line left running a full two weeks exactly as I tell everyone to.

Then I cancelled the SIM. Eight days later a weekly job started coming back empty.

It had been running on the old line the entire time. It was never in my inventory and I never noticed, because the old line was alive and working and the job was perfectly content. The overlap I was so pleased with had covered the mistake rather than exposing it.

That is the half of my own advice I had not thought through. An overlap protects you and it conceals whatever you forgot, and those are the same property viewed from two sides. So the rule now has a second clause: keep the old line up, watch its byte counter, and cancel nothing until that counter has been flat for one full cycle of your slowest job. Mine was weekly. I cancelled on day fourteen with the counter still ticking and never looked at it.

If you want Singapore lines to move onto, from someone who will happily leave the old one running while you do it slowly, that is what I run.

Get new guides and videos first — join the Telegram channel.