Moving Bitcoin miners to a new farm does not, by itself, require changing the pool account, payment method, or payout address. The key pool-side checks are whether each miner can reach the intended pool, submits accepted shares, appears under the correct account, and retains the expected settlement and payout settings.
Physical recommissioning — inventory, transport, racking, power, cooling, and local networking — still matters. This checklist focuses on mining-pool continuity alongside those tasks, assuming the pool and payment method may remain unchanged. IP addressing, DNS resolution, firewall rules, and network latency may change at the new site, so pool connectivity and worker attribution should be verified again.
Why a Farm Move Can Affect Pool Performance
Powering on a miner does not guarantee that it is hashing, and a local hashrate reading alone does not prove that the intended pool is accepting and crediting its shares. Bitcoin pooled mining works by having each miner submit shares against a pool-assigned target that is easier to meet than the network's block target; the pool uses these shares to measure contributed work and allocate rewards under its payout method. An unreachable pool endpoint, incorrect worker credentials, or an outbound connection blocked by a new firewall policy can prevent work from reaching or being credited to the intended account. Check hardware status and pool-side activity separately during a relocation.
Before Shutdown: Record the Current State
Before any miner is powered down at the old site, capture a baseline that can be compared against after the move.
- Serial number, MAC address, model, firmware version, and current rack or row location for each unit.
- The worker name currently assigned to each miner. ViaBTC's BTC worker format is
userID.workerID, where the worker ID may use lowercase letters and numbers up to 64 characters; keeping a consistent naming scheme that reflects site, row, and unit makes it easier to match physical hardware to pool-side records after relocation. - Primary and backup pool entries, including the exact Stratum URL and port in use.
- Recent local readings — hashrate, temperature, fan speed, and any hardware-status or error flags reported by the firmware.
- Pool-side worker status, the hashrate currently shown by the pool, and any rejected-share activity.
- The payout method and payout address currently configured on the account. These are account-level settings, separate from the pool and worker fields entered on the miner itself; relocating hardware does not change them, but it is worth confirming they have not been altered elsewhere.
Save a full backup of the pool configuration — including backup pool entries — before making any changes. This becomes the rollback reference if the new site encounters problems.
Prepare the New Farm Before Powering On
Infrastructure readiness should be confirmed before any miner is energized in volume.
- Rack space, PDU capacity, voltage, and cooling appropriate to the specific miner model and its operating mode.
- Airflow direction and clearance, since intake and exhaust orientation affects both individual units and adjacent racks.
- Network segmentation, DHCP reservations or static IP assignments, DNS resolution, default gateway, and confirmed outbound internet connectivity from the new site.
- Firewall and outbound-port rules checked against the pool's current documented connection method, not against an assumption carried over from the old site.
Before assuming a saved miner profile is still correct, re-verify the pool endpoint directly from current documentation. ViaBTC's Mining Pools Information page lists BTC Stratum endpoints such as stratum+tcp://btc.viabtc.io:3333, with port 443 available as a failover port, alongside additional regional and SSL options (ViaBTC Mining Pools Information). Because listed endpoints can change, operators should confirm the current addresses from the pool's official page before reusing entries from a saved configuration file or an old screenshot.
Recheck Pool Configuration Before Reusing the Old Profile
Even when the destination pool account is unchanged, the configuration entered into the miner should be re-verified rather than copied blindly.
- Confirm the coin and algorithm match the intended account.
- Copy the current Stratum URL and port from the pool's documentation, choosing the global, regional, or SSL option appropriate to the new site and supported firmware (see ViaBTC's BTC mining setup guide).
- Confirm worker-name syntax and the password field required by the pool.
- Enter primary and backup pool entries in the intended priority order; ViaBTC recommends configuring multiple ports so a miner can switch to the next connection automatically if one fails.
- Keep the previous configuration documented separately so it can be restored if the new entries cause problems.
Confirming the payment method at this stage also matters. Pool-supported payment methods are not permanent fixtures; operators should check the payout options currently available for the coin and account rather than assume continuity with a prior setup.
Commission a Pilot Group First
Where practical, bring up a small, representative group of miners — or a single unit — before powering on the full fleet. This limits the operational impact of a misconfiguration and gives a controlled baseline for the new site.
- Confirm the miner obtains an IP address or is reachable at its planned static address.
- Confirm the firmware is using the intended pool entry and worker name, not a cached or default profile.
- Review the miner's log for DNS resolution failures, connection timeouts, authorization errors, temperature warnings, fan faults, or hashboard errors.
- Confirm the worker appears under the correct pool account, not merely that the miner reports local hashing.
- Confirm the miner’s accepted-share count continues to increase and the corresponding worker shows activity under the intended pool account.
- Allow enough time before judging performance. ViaBTC notes that a miner may be checked in the pool interface after it has stabilized for roughly 10–15 minutes, which is a practical observation window rather than a universal standard.
When comparing readings, match the measurement windows. Bitmain's Antminer API exposes several local hashrate windows — including 5-second, 30-minute, and average readings, depending on the model and firmware — alongside pool connection status, accepted shares, rejected shares, and stale shares (Bitmain Antminer API Documentation). ViaBTC's pool-side figures use different windows: its real-time hashrate reflects the previous 10 minutes, while its daily hashrate reflects the prior 24 hours (ViaBTC: why pool and miner hashrate differ). After a restart, the pool’s 24-hour window may still include downtime; a newly named worker may not yet have a full day of activity. A 5-second local reading is also not directly comparable to a 10-minute pool average. Judging the move a failure based on a mismatch between these figures, without accounting for the different windows, is a common and avoidable error.
Scale Out in Monitored Batches
Once the pilot group is stable, bring the remaining miners online in batches rather than all at once.
- Use worker labels tied to the miner's physical location so that any connection or rejection problem can be traced back to a specific rack or row.
- Avoid changing firmware, overclock settings, pool configuration, and network design at the same time unless there is a clear operational reason; isolating variables makes it easier to diagnose a problem if one appears.
- Investigate any recurring rejected-share or connection pattern in a batch before expanding the rollout further. Rejected shares are the umbrella category; stale, invalid, duplicate, or low-difficulty submissions are specific causes that may be reported separately, and distinguishing them helps target the right fix — network latency, an outdated firmware build, or an incorrect pool entry.
Validate Pool Attribution and Payouts After the Move
Once the fleet is running at the new site, confirm that pool accounting reflects the move correctly.
- Check that every worker is visible and credited under the intended pool account, not just that it is online.
- Confirm the selected payout method has not changed unintentionally.
- Keep pool-account settlement distinct from an on-chain withdrawal; crediting to the account and a withdrawal to an external address are different events with different timing.
- Check whether earnings for the resumed mining period are being credited according to the selected payment method. Under ViaBTC's published PPS+ rules, the PPS block-reward component is settled hourly, while the transaction-fee component uses PPLNS allocation. PPLNS rewards depend on the applicable share lookback and block-confirmation rules (ViaBTC: How Are Profits Calculated?). Account for the shutdown period and the time each batch resumed mining when reviewing the first settlements. Early credits can help confirm that accounting has resumed, but a short post-move interval alone is not enough to assess longer-term earnings performance.
Keep a Rollback Plan
Retain the previous pool configuration, IP-plan notes, and a reliable way to identify each physical miner until the new site has demonstrated stable operation over a reasonable period. If a batch shows persistent connection or rejection problems, revert only the specific configuration variables involved — for example, the pool entry or network settings — rather than undoing the entire migration. This keeps troubleshooting focused and reduces the chance of reintroducing a problem that had already been resolved elsewhere in the fleet.
If the move also requires a firmware update, obtain the firmware only from the hardware manufacturer's verified official channel, and consider avoiding a firmware change alongside a large-scale pool or network migration unless there is a specific operational reason to combine them. Separating these changes makes it easier to identify the source of any issue that appears after commissioning.
FAQ
Does moving miners to a new farm require changing pool accounts or payout addresses?
Not necessarily. A physical relocation changes networking conditions — IP addressing, DNS, latency, and firewall rules — but it does not require changing the pool account, payment method, or payout address unless the operator decides to make that change separately. These should be verified, not assumed, since account-level settings and miner-level pool fields are configured independently.
Why does the pool dashboard show a different hashrate than the miner right after a move?
The two figures are calculated differently. Local miner readings may refresh every few seconds, while pool-side figures are typically calculated over longer windows — for example, a real-time estimate based on the previous several minutes and a daily figure based on the prior 24 hours. A recently restarted miner may have downtime within the pool’s measurement window, while a newly named worker may not yet have a full window of activity. An early mismatch can therefore reflect measurement timing, but the difference alone does not establish whether the miner is operating correctly. If pool-side hashrate remains at zero or the gap is large or persistent, check the connection, whether accepted shares continue to increase, and any rejected-share activity.
How long should a pilot batch run before scaling out to the rest of the fleet?
There is no universal duration that applies to every operation; it depends on the miner model, network environment, and how quickly the operator can confirm stable pool connection, continuing accepted-share submissions, correct worker attribution, and absence of recurring errors in the miner log. A pilot batch is primarily a tool for catching configuration problems early, not a fixed compliance checkpoint.
Should worker names be changed when miners move to a new rack or site?
Worker names can be updated to reflect the new physical location, provided the naming convention keeps the pool's required format and password-field requirements. Changing a worker name does not update the pool account's payout address or payment method, since these are separate settings.