Migrating data between Pulsed Media services

Moving from one Pulsed Media service to another is a copy, not a move: the old service keeps every file while the transfer runs, and copying between Pulsed Media servers in the same datacenter does not count toward your monthly traffic limit. The one rule that protects you: keep both services active and overlapping for at least 7 days, and never schedule the old service to cancel until every byte is verified on the new one. Switching plans? Then the data move is done for you, and nothing needs copying by hand.

The timing rule

Guideline	Value
Overlap window (both services active)	7+ days
Absolute minimum before you start	3 days of remaining time on the old service
When to cancel the old service	Only after the new one is verified complete

Reserve at least a week with both services running side by side. Do not begin a transfer if the old service has fewer than 3 days left — that is not enough runway to start safely, let alone finish.

Switching plans: the data move is included

An upgrade or downgrade between plans includes the migration: Pulsed Media migrates your data from the old service to the new one, and the old service stays active during the migration, so nothing is lost (KB: upgrading or downgrading a service). Two conditions apply:

The username must match between the old and the new service. The data migration depends on it.
Large accounts take longer. At 50 TB and above, allow a week or more.

There is no need to start your own scp or rsync copy as well. The current plans are on the seedbox page.

Why the margin is larger than the math

On paper, a few terabytes over the Pulsed Media internal network could finish in hours. Planning for hours is planning for the best case, and a data move only has to go wrong once. The 7-day window is built from what actually happens on real transfers:

Throughput is not constant. A copy that runs at tens of MB/s on large files can collapse to a crawl when it hits a folder full of small files (metadata, subtitles, .torrent files). It climbs back on its own, but the slow stretch is unpredictable and can add days.
Interruptions happen. A reboot, a maintenance window, or a dropped connection can stop a transfer partway. It resumes, but each restart costs time.
Verification takes real time. Confirming that everything arrived intact is part of the job, not an afterthought.
People need runway. If anything needs a look from support, that exchange takes time too. A margin measured in days absorbs all of this without putting your data at risk.

The math tells you the floor. The safety margin covers everything between the floor and reality.

Why a hand-made copy breaks applications

Copying the home directory with scp or rsync moves the files, not a working setup. Applications store absolute paths, and those paths contain the account username: an rTorrent session points at /home/username/..., and so do many application settings. Copied into an account with a different username, those paths point at a home that does not exist. Torrent client sessions often cannot be carried over at all, and many service settings have to be adapted to the new server (KB: migration options). The same username on both services avoids the path problem; plan to adjust application settings on the new server rather than expecting them to carry over.

How to migrate

Order and set up the new service before touching the old one. Confirm it is provisioned and you can log in.
Keep the old service active. If it is on a plan you intend to cancel, do not schedule that cancellation yet, and make sure it has well over a week of paid time remaining.
Start the transfer with both services running. Managed and do-it-yourself options are described in the migration knowledge base article.
Keep the old torrents seeding. Add each torrent to the new client paused, run a hash check, and start it only when it reaches 100%. Stop the old client only after the new one is seeding. Each tracker sets its own rules, including on seeding one torrent from two IP addresses; check them before running both clients at once.
Verify on the new service. Check that your data is present and complete before you consider the move done.
Only then retire the old service. Once you have confirmed everything landed, cancel or let the old service lapse.

Your old service is your safety net

A migration is a copy. Nothing is deleted from your old service during the transfer, so throughout the move your data lives in two places at once. That redundancy is the whole point of the overlap window. As long as the old service is alive, a failed or incomplete transfer costs you time, never data. The moment the old service is gone, that safety net is gone with it. Keep it until you are certain.

Troubleshooting

The transfer slowed to a crawl. Most often this is a stretch of small files, not a problem with the network or the hardware. It usually recovers on its own. If it stays pinned slow across large files too, open a support ticket.
The transfer stopped partway. Restart it — a well-behaved copy resumes from where it left off rather than starting over. This is exactly what the overlap window is for.
Torrents on the new service show missing data. Usually the copy is not finished yet. Leave them paused, let the copy complete, and recheck; the old client keeps seeding meanwhile.
The old service is close to expiring and the move is not done. Extend or renew it so the overlap holds. Never let the old service lapse while a transfer is unconfirmed.