NixOS Flakes transition: managing configuration drift during channel migration

Transitioning from Channels to Flakes

NixOS traditionally relies on channels to manage system updates, where the state is derived from implicit channel versions. The introduction of Flakes shifts this model toward explicit dependency pinning via a flake.lock file to ensure absolute reproducibility across environments.

Compatibility and State Management

When transitioning a production system from channel-based deployments to a Flake-based workflow, there is a potential for configuration drift. This occurs because the nixos-rebuild command behaves differently depending on whether it is targeting a traditional configuration.nix or a Flake output.

Given that Flakes require the experimental-features = nix-command flakes configuration in nix.conf, the interaction between legacy channel updates and the new lock-file mechanism remains a point of operational uncertainty.

• How does NixOS handle the coexistence of channel-defined packages and Flake-pinned inputs during a phased migration?
• What is the documented behavior for resolving version conflicts when a system is partially managed by both mechanisms?