I'm a systems administrator at a VFX and animation studio with roughly 400 users. We're starting a project to move artist workstations from Windows 10/11 VDIs to Linux, and Rocky Linux 9 with KDE is currently the planned platform. I'd like to hear from anyone who has managed a similar migration. Which distribution did you choose, and would you make the same choice again? How did you replace the controls and policies previously handled through Group Policy? What did you use for deployment and configuration management—Kickstart, PXE, Puppet, Ansible, Foreman, or something else? I'm especially interested in prototype and pilot strategies, application compatibility, storage and identity integration, help-desk preparation, and the problems that seemed simple but became unexpectedly difficult. Any lessons learned, successful approaches, or cautionary war stories would be appreciated.
4 Answers
The biggest risks are usually applications and shared storage, not the operating system. Linux is a strong fit for many VFX workflows, especially when the studio already relies on tools such as Nuke, Houdini, Maya, Resolve, or Fusion and has a Linux-based render pipeline. However, test every DCC, plugin, GPU driver, color-management workflow, license service, and pipeline tool on the exact Rocky release you intend to deploy. Keep Windows or macOS available for exceptions such as Adobe, Cinema 4D, or applications that behave poorly under Wine. Mixed Windows/Linux/macOS access to SMB and NFS storage can also create subtle ownership and permissions problems.
Treat this as a greenfield platform rather than translating every Group Policy setting one-for-one. Use AD integration through SSSD for identity and access, then apply Linux-native controls with configuration files, permissions, sudo rules, SELinux, system services, and automated roles. Start with a minimal desktop containing only the applications and services each role actually needs. That usually gives you better consistency and fewer ways for users to accidentally disrupt their systems.
That’s close to the approach we’re planning. We’re auditing the existing policies first so we can keep the controls that matter across platforms and discard the accumulated cruft.
Do not skip the pilot. Test first with an IT or technical user to prove the deployment and recovery process, then move one real artist from each major job role. Ask them to perform their normal work rather than just checking whether the desktop boots. Plan for training and a large increase in help-desk requests, even if KDE feels familiar. Include a rollback path, reliable backups, persistent home directories, and clear ownership between desktop support, pipeline, and application teams. Also consider the workstation lifecycle: Rocky 9 may eventually require a reinstall or a carefully planned migration, so build that process before hundreds of machines depend on it.
The support impact is definitely a concern. We’re planning a small beta group, followed by department-by-department deployment with training, feedback, and a way to reverse the change if a critical workflow fails.
For Rocky deployments, PXE with Kickstart followed by Ansible or Puppet is a very standard route. Foreman can make the workflow easier by handling PXE, host groups, provisioning, updates, and package version control. A new machine can boot from the network, select its profile, install the base system, and receive its configuration without much manual work. Keep the roles modular—for example, a general artist workstation plus additional roles for Houdini, Nuke, compositing, or pipeline tools.
We’ve had good results with phased rollouts: one representative machine per team, fix the team-specific issues, then turn those fixes into automation before expanding the deployment.
That matches our situation. The technical-art and pipeline teams are testing the artist applications while the desktop team concentrates on identity, deployment, storage, and support.