For over a decade, Windows was my home. I knew its quirks: the exact moment a blue screen was coming, the registry hacks to kill Cortana, the safe distance to keep from a Windows Update notification. But in early 2025, after one too many forced restarts and a creeping feeling that my development environment had become a collection of band aids held together by WSL2 and hope, I decided to rip the bandage off. I would migrate everything, my coding, design, writing, gaming, and daily computing, to Linux.
Spoiler: it worked. Today, my entire workflow lives happily inside a Linux machine. But the migration was a fever dream of missing fonts, Wi Fi drivers that momentarily turned my laptop into a paperweight, and a lot of lessons I didn’t expect. This is the story of that move, the gotchas, and the three things I would absolutely do differently if I had to start over.
Why Leave Windows in the First Place?
This wasn’t a political decision. It was purely practical. My day to day work revolves around Python backend services, some embedded C, Docker containers, and occasionally Go. Windows Subsystem for Linux (WSL2) had served me well, but the minute I started needing multiple terminals, pass through USB devices for flashing microcontrollers, and a native file system that didn’t choke on thousands of small files inside node_modules, WSL2 felt like a cleverly engineered cage.
I was spending more time fighting path translations and memory limits than I was shipping code. Docker Desktop had become a resource hungry subscription reminder. One Tuesday, after a Windows update broke my GPU passthrough to WSLg and corrupted a kernel driver I needed for an STM32 debugger, I opened a terminal and typed ssh into the old ThinkPad I’d been meaning to repurpose as a home server. That machine was running Ubuntu 22.04. By Thursday, I had ordered a second SSD for my main desktop. The plan was simple: dual boot until I didn’t need Windows anymore. I never imagined how messy “simple” could get.
Picking a Distro and a Desktop (The First Fork in the Road)
For someone coming from Windows, the universe of Linux distributions is paralyzing. I’d used Ubuntu on servers for years, so that was the safe bet, but desktop Linux is a very different beast. After a week of distro hopping in virtual machines, I landed on Fedora Workstation with GNOME. Not because I loved GNOME (at first, I actually found its minimalism unsettling) but because Fedora ships near vanilla upstream packages, has a six month release cadence that keeps things fresh without the rolling release chaos of Arch, and has the best out of the box Secure Boot support I could find.
Why not Linux Mint? I tested it. It’s wonderful. The Cinnamon desktop feels like Windows 7’s calmer, more competent sibling. But I wanted a workflow that forced me to rethink my habits rather than simply replicating the Start Menu. I knew myself well enough to know that if a Linux desktop looked too much like Windows, I’d fall into the trap of expecting it to behave identically, and I’d be frustrated when it didn’t.
I installed Fedora 39 on the fresh SSD, keeping my Windows drive physically disconnected during installation to avoid bootloader heartbreak. This turned out to be one of the few smart things I did.
The Migration: Workflow by Workflow
I didn’t try to move everything at once. I broke my workflow into six pillars and moved them one at a time, staying in Fedora for that pillar until I wasn’t tempted to reboot into Windows anymore.
1. Coding Environment (Week 1)
This was supposed to be the easy part. I’d lived in bash shells inside WSL2 for years. I installed VS Code, Git, Docker Engine (not Docker Desktop, another win), Python, Go, and my usual suite of linters. Straightforward. The first real shock was how much faster everything felt. File watchers that took 200ms on WSL2 took 15ms natively. A test suite that ran in 45 seconds on Windows consistently finished in 31 on Linux on the same hardware. I later measured the difference and realized I’d been leaving maybe 30% of my hardware’s potential on the table because of the WSL2 virtualization layer and NTFS’s inefficiency with small files.
The real trouble began with fonts. Every code editor I opened looked subtly wrong until I realized Windows’ font rendering system had been shaping my perception of monospace fonts for years. JetBrains Mono, my go to, looked thinner on Linux. I spent half a day tweaking fontconfig and installed the Microsoft Core Fonts package just to reunite with Consolas for terminal usage. It felt like a defeat, but it made the code legible to my eyes again.
2. Writing and Note Taking (Week 1 to 2)
My writing stack was Obsidian backed by a git repo, plus a handful of Python scripts for generating blog metadata. This migrated in about twenty minutes. The Obsidian Flatpak worked perfectly. My scripts ran without changes because I’d always used POSIX paths inside WSL2. For the first time, I felt smug.
3. Design and Media (Week 2 to 3)
I don’t do heavy graphic design, but I do enough: Figma in the browser for wireframes, GIMP for occasional raster edits, Inkscape for vector work, and Kdenlive when I need to cut video. Figma was identical. GIMP and Inkscape, once I accepted their UI paradigms, were actually more responsive than their Windows counterparts. Kdenlive was the surprise: on Fedora, it rendered a 4K test timeline 20% faster than DaVinci Resolve on Windows, though I later discovered this was because my AMD GPU’s open source drivers on Linux handled the encoding pipeline better than Windows’ proprietary driver for that version.
The big loss was the Affinity suite. I had long been a casual Affinity Photo user in Windows, and there is no native Linux version. I tried running it via Wine; it launched, crashed frequently, and finally corrupted a file I cared about. I abandoned the attempt and committed to GIMP and Inkscape. If design were my primary job, this would have been a serious problem. As it stood, it was a manageable downgrade.
4. Communication and Browsing (Week 3)
Browser migration was painless: Firefox sync brought everything over. I also installed Chromium for testing web apps. Slack, Discord, and Telegram all had native Linux clients or functional web versions. Zoom’s Linux client, however, decided to remember every audio device I had ever owned and default to one that didn’t exist. I spent an infuriating afternoon in pavucontrol before marking it down as “works, just with extra steps.”
5. Gaming (Week 3 to 4)
This is where things got real. I’m not a hardcore gamer, but I do play a handful of titles: Celeste, Hollow Knight, Stardew Valley with a friend, and the occasional indie roguelike. Proton, Steam’s compatibility layer, has become magical. All these titles ran with zero configuration.
But I wanted to test a slightly more demanding game, The Witcher 3, which I owned on GOG. Through Lutris, I got it running, but the initial launch took 15 minutes of shader compilation and I had to manually adjust the game’s configuration file to disable a broken fullscreen mode. Once it worked, it was smooth, but the process wasn’t “click and play.” I realized that on Linux, gaming remained a hobby that rewarded your willingness to read a forum post. If I were primarily a PC gamer with a large library of competitive anti cheat titles, I’d have kept a Windows partition without guilt. I did anyway; I kept the dual boot for exactly two games that refused to cooperate.
6. The Final Boss: Email and Calendar
I’d used Outlook (the desktop app) for years. I tried Evolution, Thunderbird, and Mailspring. Mailspring came closest, but the lack of seamless Exchange support for my work email forced me to use the Outlook web app. This was a lateral move at best. The biggest friction was forgetting that the web app doesn’t send desktop notifications by default. I missed a meeting. I fixed it with a browser notification rule and moved on.
The 3 Things I’d Do Differently
After months of living inside Fedora, I can say the migration was worth it. My machine boots in under 8 seconds, I never lose a terminal session to an update, and my development environment feels native for the first time. But there were three mistakes I made that, if I could talk to my past self, I’d scream into the void to avoid.
1. I Would Have Dual Booted (Properly) for Six Months Instead of Three Weeks
My plan was aggressive: force myself into Linux by making Windows inconvenient. I kept Windows on a separate drive, but in my initial boot order, I hid the Windows boot entry to prevent myself from reflexively going back. This psychological trick worked, but it also meant I hit a critical path problem on a Thursday night when a client’s project suddenly needed a firmware flashing tool that only had a Windows binary. I scrambled for two hours trying to get wine and USB passthrough to cooperate. I couldn’t. I ended up rebooting into Windows at 11 p.m., feeling defeated.
If I were doing it again, I’d keep Windows visible in the boot menu and actively choose to boot Linux each morning. That conscious decision would have preserved my sense of agency and avoided the one emergency where I had to break my own rule. The goal shouldn’t be to trap yourself; it should be to build trust in the new system. I’d recommend a gradual, parallel existence where you do 80% of your work in Linux but keep Windows as a known good backup for at least two months, not three weeks.
2. I Would Have Started with a Distribution That Matches My Hardware, Not My Ideals
Fedora is fantastic on my desktop with an all AMD build. Open source drivers for AMD GPUs and CPUs are baked into the kernel, and everything worked out of the box. But I also have a 2 in 1 Dell laptop with an active stylus, a fingerprint reader, and a rotation sensor. Fedora on that laptop was, for a solid month, a parade of searches for kernel parameters. The touchscreen worked but the stylus didn’t register pressure, the fingerprint reader was a lost cause, and screen auto rotation required a custom iio sensor proxy tweak that I never fully trusted.
Eventually, I installed Ubuntu 24.04 LTS on that laptop, and the Dell specific firmware support (fwupd updates, preconfigured drivers) made everything mostly functional. I learned the hard way that laptop hardware support can still be a “distro shopping” exercise. The smarter move is to research your exact laptop model on the Arch Wiki and Ubuntu certified hardware lists, and look for forum threads where people document what worked. If I’d done that, I would have saved about 20 hours of troubleshooting. Choose the distro that your hardware loves, not the one you find philosophically purest.
3. I Would Have Kept a “Windows in a VM” Solution Ready from Day One
About three months into my full time Linux life, I got a freelance contract that required Adobe Acrobat Pro for digitally signing and validating a specific government PDF format. No Linux PDF reader could handle the XFA form correctly, and the online Adobe Sign service refused the document’s metadata. I had to use Windows.
Instead of rebooting, I set up a Windows 10 virtual machine using KVM/QEMU with virt manager. The performance was shockingly good, near native for a lightweight task like PDF signing, because I’d configured GPU acceleration. I wish I’d done this before the migration even started. A VM gives you a “safety net” Windows environment that boots inside Linux, without the overhead of dual booting. For those random vendor tools, firmware updaters, or proprietary file format problems, it’s the perfect compromise. I now keep a minimal Windows VM with only the essential proprietary tools installed, and it has completely removed the anxiety of “what if I need Windows for one thing.” I’d recommend pre building that VM before you delete or hide your Windows partition.
What I Gained (and What I Lost)
After six months, the gains were clear. My development machine no longer felt like a hostile landlord; it felt like a workshop I could rebuild from scratch. My system hasn’t crashed once. I update when I want. I’ve contributed to two open source projects whose build processes were Linux only, and I didn’t have to spin up a container to do it. My terminal is no longer a window into another operating system. It is the operating system.
The losses are real but shrinking. The Affinity suite gap hasn’t closed, and I remain dependent on the Windows VM for a few proprietary work tasks. Gaming remains a “check ProtonDB before purchase” culture, though 80% of my library works perfectly. I miss the polish of Windows Hello facial recognition, but typing my password has not killed me.
Final Advice for the Curious
If you’re reading this and considering your own migration, here’s my distilled advice, drawn from the scar tissue.
Start with a secondary machine or a VM. Don’t nuke your main rig. Spend a month just living in Linux for a subset of tasks.
Hardware compatibility is everything. AMD GPUs and Intel Wi Fi chipsets will save you days of pain. If you have NVIDIA, be prepared to become deeply familiar with driver version negotiations.
Don’t try to replicate Windows. Learn the Linux way of doing things. You’ll be less frustrated and more effective.
Backup everything first. I did, and the one time I accidentally wrote a partition table to the wrong drive, I thanked my past self through gritted teeth.
Keep a Windows VM alive. It’s a 15GB insurance policy against every proprietary curveball the world can throw at you.
The migration from Windows to Linux is not a one time event; it’s a gradual shift in how you think about the tools you use. My workflow today is faster, more transparent, and entirely my own. The three things I’d do differently aren’t regrets. They’re signposts for anyone else ready to cross the chasm. I wish I’d had this list before I started. Hopefully, it makes your journey just a little bit smoother than mine.
