Upgrading Frostlabs

“My biggest challenge is that I’ve never done a migration like this before. I know Docker and I understand Swarm conceptually - I built the cluster with p0 and the Pis - but this is different. This is taking a working system with all my media services and configs and moving it to a completely different orchestration model without breaking everything.

I’m worried about the details. How do I handle the GPU for Emby transcoding? How do the storage mounts work when services are running in containers managed by Swarm instead of Unraid? What happens to all my appdata configs during the migration? I’ve got years of Sonarr/Radarr configuration I can’t lose.

And honestly, I’m second-guessing myself constantly. Should I keep Unraid or nuke it? Do I really need HA with three managers? What about THOR - should it be in the cluster or not? I keep flip-flopping because I don’t want to over-engineer this, but I also don’t want to regret skipping something important.

The technical stuff I can figure out, but it’s the ‘what’s the right approach’ decisions that are slowing me down. I need someone who’s done this before to tell me ‘yes, this is the way’ or ’no, you’re overcomplicating it’ so I can just commit to a plan and execute without constantly wondering if I’m doing it wrong.”

“Don’t overthink the architecture before you understand the actual constraints.

I spent all this time planning a three-manager HA setup with THOR, trying to get Hyper-V networking working, debugging WSL2, fighting with VLANs - all for marginal HA benefits I don’t actually need. My services aren’t life-critical. If p0 or p4 goes down for maintenance, the world doesn’t end.

The simpler solution was staring me in the face the whole time: beef up the existing test VM (p4), keep Unraid doing what it’s good at (storage), and just mount everything via 9p. No data migration, no downtime, no complexity. Two managers is fine for my use case.

I also learned to recognize when I’m being a ‘glutton’ - wanting features because they’re cool, not because I need them. HA across VLANs with a gaming desktop? That’s complexity for complexity’s sake.

The biggest lesson: start with what works, expand when you actually need it. I already had p4 in the swarm as a test VM. All I needed to do was give it more resources and start migrating services one at a time. Everything else was just me getting in my own way.

And maybe the meta-lesson: when someone experienced says ‘you’re overcomplicating this,’ actually listen instead of pushing forward with the complicated plan anyway.”

“First, I need to actually start migrating services. All this planning and infrastructure work means nothing until I deploy something and prove the whole setup works end-to-end.

Pick one simple service - probably Sonarr or Radarr - create a stack file, deploy it to the swarm with the right constraints and labels, make sure it can access the Unraid storage, and confirm it actually works. Then stop the Unraid version and call it a win.

Once I’ve done one service successfully, I’ll have a template. Then it’s just rinse and repeat - migrate services one at a time at my own pace. No rush, no pressure. Each one that moves over is progress.

The media stack services come last since they’re the most critical and I want to make sure everything else works smoothly first. Emby especially - I need to be confident the GPU passthrough and transcoding work properly before I move that over.

Document everything as I go. Create a stack files directory structure, keep notes on what works and what doesn’t, build my own playbook so when I do expand later or rebuild something, I’m not starting from scratch.

And honestly? Just do it. Stop planning and start deploying. The foundation is solid - p4 is ready, storage is accessible, the swarm is functional. Time to actually use what I built.”