Choosing between pinned and history‑based conda environment exports for downtime‑free migration after Anaconda 2024.06 ToS change

Answer

Use a history‑based export (conda env export --from-history) and target the conda‑forge channel. This avoids the defaults‑channel licensing implications of the 2024.06 ToS change while allowing the solver to re‑resolve dependencies for the target OS/architecture, giving a good balance of reproducibility, portability, and compliance.

Confirmed facts

• A pinned export records exact build strings; it is bit‑for‑bit reproducible only on the same platform and still pulls from the defaults channel, so it does not sidestep the new licensing terms.
• A history‑based export lists only explicitly requested top‑level packages (no versions unless you pinned them at install time), letting conda’s solver choose compatible versions for the target host.
• Anaconda’s 2024.06 ToS generally exempts organizations under 200 employees and certain non‑commercial uses from paid licensing for the defaults channel, but the exact thresholds must be verified in the current ToS.
• For a downtime‑free move, you can build and validate the new environment on the target host (or a staging clone) while the old host continues serving traffic.

Likely explanation / recommendation

Because the application is small and you want to avoid service interruption, the safest path is to let the solver re‑resolve dependencies on the new machine. This protects you from:

1. Licensing risk: by removing the defaults channel and using conda‑forge only, you stay outside the scope of the paid‑license requirement.
2. Portability issues: the solver will select builds that match the target OS/CPU architecture, whereas a pinned linux‑64 export would fail on macOS or Windows.
3. Version drift risk: you can mitigate unintended upgrades by adding explicit version pins for any behavior‑critical packages in the generated environment.yml.

Steps for this case

1. On the current host, create the history‑based file:

   conda env export --from-history > environment.yml

2. Edit environment.yml to ensure the channels section lists only - conda-forge (remove defaults). Add any necessary version pins for critical packages, e.g.: - numpy=1.26.4.
3. On the target host (or a staging clone), create the environment:

   conda env create -f environment.yml

4. Activate the new environment and run the application’s test suite or smoke checks to confirm behavior matches expectations.
5. Compare package lists between old and new hosts with conda list --explicit to spot any unexpected upgrades before cutover.
6. Once validation passes, switch traffic to the new host (or new port) and decommission the old environment.

Missing diagnostic detail

Please confirm whether your organization exceeds 200 employees or engages in commercial use that would require a paid Anaconda license for the defaults channel, as this affects whether retaining defaults is permissible.