Seven angles, one spine: a migration asks two independent questions, and almost every “try Linux safely” option answers only one. Does your software survive — .NET SDK, Node/TS, Docker, git, shell? And does your machine survive — suspend/resume, Wi-Fi, GPU, docking, battery, the desktop itself? Everything virtualised answers the first at near-perfect fidelity and the second at zero: WSL2 blocks kernel modules, routes USB through usbipd, and hands you a NAT adapter with a fresh IP each restart [1]. A live USB inverts it — 15 minutes, €10, and it tells you whether your Wi-Fi and dock enumerate at all [2].
That split produces a convergent recommendation the angles reached independently: WSL2 → live USB → full install on an external NVMe SSD → commit, with dual-boot skipped. The external SSD is the only rung that is simultaneously full-fidelity and zero-commitment — real kernel, real drivers, real four-week trial, and undo means unplugging [3]. Single-disk dual-boot buys nothing it doesn’t, at the price of partition surgery, a documented BitLocker recovery trigger [4], and Windows updates that have broken Linux boot before [5]. If you do want Linux inside the chassis, the dual-boot angle’s layout — second physical disk, its own ESP, F12 to switch, Secure Boot left on — is the version with the smallest blast radius [6].
Where the angles disagree: how long to sit on WSL2. The WSL2 deep-dive argues 3–6 months to fully retire userland risk; the ladder says 2–4 weeks, because WSL2 cannot start answering the hardware question and time spent there is time the real risk stays untested. Take the shorter number if your hardware is unknown, the longer one if it’s on Ubuntu’s certified list [7].
The theme that repeats three times, from three directions: a git working tree belongs on a native Linux filesystem owned by one OS. Under /mnt/c it is ~34× slower on random reads [8]. On a shared NTFS partition it loses the exec bit, case-sensitivity and symlinks — and the in-kernel ntfs3 driver is being actively re-litigated on LKML in 2026 [9]. In a sync folder, concurrent changes “can result in a corrupted Git repository” [10]. Same rule, three failure modes.
One correction worth flagging: Dropbox’s ext4-only rule ended in 2019 — btrfs, zfs and xfs are officially supported [11], so btrfs snapshots are not blocked. The real hazard is subtler: rolling back a subvolume containing ~/Dropbox looks like mass deletion to the client, and in a shared folder deletions propagate to everyone [12]. Keep ~/Dropbox on a subvolume Timeshift doesn’t touch. And you cannot point Windows Dropbox and Linux Dropbox at one partition — the overlap needs two linked installs [13].
The sharpest open question none of this resolves: whether your specific machine suspends, docks and drives external displays cleanly. That is empirical, it costs one evening and a USB stick, and every downstream decision is gated on it.