A pool migration is the process of changing the mining pool endpoint a fleet of ASICs points to, and in many cases also changing the account, worker-naming convention, payment method, or mining mode associated with that fleet. It sounds like a configuration change, but it also functions as an accounting change: shares submitted after the cutover are credited under a new set of pool rules, and earnings credited before and after migration are not automatically comparable.

A written migration plan reduces two common failure modes. The first is a configuration error that leaves machines connected and hashing but credited to the wrong worker or account. The second is a premature conclusion that the migration "reduced hashrate" or "reduced revenue" when the real cause is a mismatch between how the ASIC calculates and displays its local hashrate and how the pool calculates its own hashrate estimate over a different time window. This article sets out the components a pool migration plan should include and the order in which they should be executed.

What a Pool Migration Plan Should Cover

At minimum, a migration plan should document eight things: the objective and scope of the migration, a baseline of the current pool configuration and settlement status, the verified destination-pool configuration, a pilot group and rollout sequence, a deliberate primary/backup pool order, a monitoring approach that separates device-side and pool-side data, an acceptance check before scaling to the full fleet, and a reconciliation step that closes out the migration formally.

Each of these is addressed below as a discrete step.

Step 1: Define the Migration Scope

Before touching any miner, define what is actually changing. At a minimum, record:

• The coin and mining algorithm involved (for example, BTC on SHA-256).
• Which sites, containers, racks, or logical miner groups are included in this migration versus excluded or deferred.
• Whether the change is limited to the pool endpoint, or whether it also changes the payment method, worker-naming format, mining mode (such as a smart-mining or coin-switching feature), or account structure.
• Whether miners will retain the original pool as a secondary entry during the pilot phase, or whether the original account will be closed immediately.

There is no single correct pilot size or observation period that applies to every operation. The right scope depends on fleet size, site topology, firmware version, and how much interruption the operation can tolerate. A single-site operator running a few dozen units has different constraints than a multi-site operation coordinating hundreds of machines across shifts, and the plan should state its own reasoning rather than copying a fixed number from an unrelated operation.

Step 2: Capture a Baseline Before Changing Any Miner

A migration plan is only useful for comparison if it records the pre-migration state first. Baseline fields worth documenting include:

• Miner IP address or asset identifier, ASIC model, and firmware version.
• Local hashrate reading and, where the firmware documents it, the averaging or calculation window behind that metric. If the interface also has a stated dashboard refresh interval, record that separately rather than treating it as the hashrate averaging window.
• Current pool URL, port, worker name, and pool-priority order.
• Current pool-side hashrate view and the time window that figure represents.
• Rejected-share rate, and any rejection reasons the pool interface reports.
• Current payment method, the applicable fee structure by reward component where relevant, unpaid balance, and withdrawal settings.
• The exact start time of the comparison period, so post-migration figures can be aligned to a matching window.

This is also the point to make explicit, in the plan itself, that local hashrate, pool-estimated hashrate, submitted shares, and credited mining revenue are related but not interchangeable figures. A pool does not observe an ASIC's raw computation directly; it observes shares and estimates hashrate from the rate and difficulty of the accepted work it receives. For Bitcoin, a share is a proof-of-work submission that meets a pool-assigned target that is easier to reach than the network target (Bitcoin Developer Guide: Mining). The easier pool target has a higher numeric target value and corresponds to a lower difficulty than the Bitcoin network target. Keeping this distinction explicit in the baseline prevents the plan from mixing device-side and pool-side numbers later.

Step 3: Verify the Destination Pool Configuration

Before any miner is repointed, pull the destination pool's current configuration directly from its official documentation rather than from a saved template or a forum post. At minimum, confirm:

• The primary Stratum URL and port, and any backup URL or failover port.
• Regional endpoints, if the pool offers them, and an SSL endpoint if both the pool and the miner firmware support it.
• The required worker-name format and password rules.
• Supported payment methods and the specific method selected for this migration.
• The pool's applicable fee structure for the selected payment method, including separate fee treatment by reward component where relevant.
• Settlement timing and withdrawal rules.
• Any mining-mode setting relevant to the coin, such as a smart-mining or coin-switching feature.

ViaBTC's mining pool connection page lists current URLs, failover ports, regional endpoints, SSL addresses, and supported payment methods by coin, and its BTC mining setup guide documents the userID.workerID worker format and multiple available ports. For ViaBTC Smart Mining, the current documented mode is One-click Switch, available for the Bitcoin pool covering BTC and BCH (ViaBTC: What Is Smart Mining?). Pool connection details and product settings are maintained pages, not static values, so the plan should reference the live documentation rather than relying on a saved configuration that may later become outdated.

Step 4: Design the Pool Priority and Rollback Path

Most ASIC firmware allows several pool entries in a priority order, and lower-priority entries are typically used only when a higher-priority pool becomes unreachable, not because it offers a better estimated payout. Bitmain's S21 XP Hyd. installation guide, for example, documents three pool slots (Pool 1 through Pool 3) in decreasing priority, where a lower slot is used only if the pools above it are offline (Bitmain S21 XP Hyd. Installation Guide). That behavior makes the configured order a deliberate operational decision rather than a convenience setting.

During a pilot, an operation may place the destination pool in the highest-priority slot and keep the original pool as a lower-priority backup, so that a connectivity failure at the new pool does not idle the miner. Before scaling beyond the pilot, confirm — for the specific ASIC model and firmware in use — that failover triggers on unreachability rather than on any other condition, and record the exact URL and port configured in each slot so the rollback path can be reproduced without guesswork.

If the previous pool remains configured as a failover entry, the cutover time should not be treated as a perfectly clean accounting boundary. A temporary failure of the destination endpoint can cause the miner to resume submitting shares to the previous pool after the nominal cutover. Record any failover periods and check the previous pool for post-cutover shares or earnings during reconciliation.

Step 5: Test With a Pilot Group

Before repointing the full fleet, migrate a small group of miners and check, in order:

• The miner connects successfully to the destination endpoint.
• The worker appears under the intended account with the correct worker name.
• Shares are being submitted and accepted.
• Pool-side hashrate begins to populate after the pool's stated observation period; ViaBTC's guidance notes that a worker may take approximately 10–15 minutes to stabilize before its status and earnings can be meaningfully reviewed, and that a newly connected worker may take 10–20 minutes to appear as active (ViaBTC BTC Mining). This is product-specific operational guidance from ViaBTC's documentation, not a universal industry threshold, and other pools may specify different observation windows.
• The rejected-share rate has not increased beyond its baseline range.
• ASIC temperatures, fan speeds, and chip or board status remain within their normal operating range for that hardware.
• The configured backup pool is reachable if the primary connection is deliberately interrupted as a test.

Step 6: Roll Out in Stages and Monitor the Right Data

Where continuity matters, move miner groups in stages rather than repointing the entire fleet simultaneously, so that a configuration problem affects a bounded subset of machines rather than the whole operation. During and after rollout, keep three categories of monitoring data separate rather than treating them as one combined view:

A frequent source of false alarm is comparing an ASIC's local hashrate against a pool's short-window estimate as though the two were measuring the same thing. ViaBTC's documentation states that its real-time pool hashrate figure is calculated from the preceding 10 minutes, while its daily statistic represents the prior 24 hours. The same documentation separately notes that a mining-machine interface may refresh its displayed value every five seconds; that refresh rate does not mean the local hashrate itself is a five-second average (ViaBTC: Why the Pool Hashrate May Differ From the Miner). A temporary gap between the two dashboards immediately after cutover should not be treated as evidence of lost mining capacity until the underlying calculation periods are understood and the readings are compared over a compatible window.

Step 7: Reconcile Payouts and Close the Migration

A migration is not complete once miners are connected and submitting shares; it is complete once the financial transition has been reconciled. Before closing the migration:

• Confirm the final balance and withdrawal status at the previous pool, including any earnings generated after the nominal cutover because the old pool was retained as a failover entry.
• Verify that the destination account, withdrawal address, and withdrawal settings are correct.
• Record the cutover time alongside the corresponding dashboard state at both pools, together with any post-cutover failover periods, so later questions about a specific period can be traced back to a known configuration.
• If the payment method itself changed as part of the migration, treat before-and-after revenue comparisons with care. ViaBTC's current PPS+ arrangement applies PPS logic to the block-reward component with a 4% fee and PPLNS logic to the transaction-fee component with a 2% fee. The transaction-fee component is calculated based on the user's share of pool hashrate over the last five difficulty rounds when a block reaches six confirmations. Under ViaBTC's PPLNS payment method, block rewards and transaction fees are calculated together under PPLNS with a 2% fee (ViaBTC: How Are Profits Calculated?). These methods should not be compared as if they used the same calculation and variance profile.
• Do not assume that PPLNS-style rewards stop precisely when a miner is repointed away from a pool; payment can depend on the pool's specified share window and block-confirmation process, so a final reconciliation may need to wait until that settlement completes.

Only after this reconciliation step should the migration be considered closed, with both the prior pool's final settlement and the destination pool's first settlement period reviewed and recorded.

Pool Migration Plan Template

The following structure can be adapted to most fleet sizes without adding unnecessary process overhead:

Conclusion

A pool migration plan does not promise higher revenue, and it should not be written as though it does. What it provides is a controlled way to change endpoints, confirm that shares are being submitted and credited to the correct account, preserve a working fallback path if the destination pool becomes unreachable, and compare results only once the measurement windows and payment methods on each side are actually compatible. Treating the migration as both a connection change and an accounting change — rather than a single configuration edit — is what keeps the before-and-after comparison meaningful.

FAQ

Do I need to stop mining during a pool migration?

Not necessarily. Many operations keep the previous pool configured as a lower-priority backup entry while the destination pool is tested, so a miner can continue submitting shares even if the new endpoint is briefly unreachable. Whether this is practical depends on the specific ASIC firmware's support for multiple pool entries and its failover behavior. If the previous pool remains available as a backup, any post-cutover failover period should also be included in the final reconciliation.

How long should I wait before judging whether the migration worked?

There is no fixed industry duration, and different checks can be made at different times. Connection status, worker authorization, and accepted shares can be verified first. Pool-estimated hashrate should then be judged only after enough time has passed for the pool's stated calculation window to populate. A 24-hour statistic requires more patience: until a full 24 hours has passed after cutover, that trailing window may still include pre-migration time and should not be treated as a clean post-migration comparison.

Why does the pool show a lower hashrate than my miner's display right after migration?

This is often a measurement-window difference rather than a hardware problem. A miner and a pool can calculate hashrate over different periods, while their dashboards may also refresh at different intervals. For example, ViaBTC calculates its real-time pool hashrate from the previous 10 minutes and its daily statistic from the previous 24 hours, while a miner interface may refresh its displayed value more frequently. Compare the calculation basis of each metric rather than assuming that two simultaneously displayed numbers represent the same measurement period.

Should I switch payment methods at the same time as the pool endpoint?

That is an operational decision that depends on the destination pool's available payment methods and the operator's own comparison needs. Changing both at once makes it harder to isolate whether a change in results came from the new endpoint, the new payment method, or normal variance in mining income, so many operators prefer to change one variable before evaluating the other.

What should be reconciled before considering the migration complete?

At minimum, the final balance and withdrawal status at the previous pool, any post-cutover shares or earnings caused by failover back to that pool, correct account and withdrawal configuration at the destination pool, and confirmation that the destination pool's settlement rules have had time to apply before any revenue comparison is drawn.

References

• Bitcoin Developer Guide: Mining — https://developer.bitcoin.org/devguide/mining.html
• ViaBTC, Mining Pools Information — https://support.viabtc.com/hc/en-us/articles/14367481714191-Mining-Pools-Information
• ViaBTC, BTC Mining setup guide — https://support.viabtc.com/hc/en-us/articles/7207401012879-BTC-Mining
• ViaBTC, What Is Smart Mining? — https://support.viabtc.com/hc/en-us/articles/7207430158095-What-is-Smart-Mining
• ViaBTC, Why Is the Hashrate Shown in the Mining Pool Lower Than That of the Mining Machine? — https://support.viabtc.com/hc/en-us/articles/7574354263183-Why-is-the-Hashrate-Shown-in-the-Mining-Pool-Lower-than-that-of-the-Mining-Machine
• ViaBTC, How Are Profits Calculated? — https://support.viabtc.com/hc/en-us/articles/7207397084047-How-are-profits-calculated
• Bitmain, S21 XP Hyd. Installation Guide — https://support.bitmain.com/hc/en-us/article_attachments/38059059949977