Puppet Enterprise migration is not a religious war. It is a bill, a console, and a compiler farm. OpenVox is the community continuation of Puppet open-source. If your modules, Hiera, and r10k control repo are healthy, you can keep the language and stop paying for a GUI you can replace.
What you are actually migrating
- Agents and catalogs — OpenVox speaks the same desired-state language. Roles, profiles, and Forge modules transfer.
- Compilers and CA — The Large Environment Installation pattern still applies: CA separate from compilers, load-balanced catalog compilation, PuppetDB for facts/reports.
- Code deploy — r10k (or your Git → environment pipeline) stays. PE Code Manager is the piece you replace with something you own.
- The console — This is the emotional part. openvox-gui covers fleet status, certificates, Bolt, and Hiera for teams who missed the PE Console.
A sane sequence
1. Health check the current estate (PE or Community). Write down node count, compiler layout, Hiera 3 vs 5, legacy facts, and who can still explain site.pp.
2. Pilot OpenVox on a non-prod environment. Prove agent bootstrap, catalog compile, and a module you care about.
3. Stand up a console if operators need one — do not pretend SSH is a product.
4. Cut over in a change window you would defend to an auditor. Rehearse. Keep a rollback that is not “restore from backup and pray.”
5. Stay or leave. CMaaS is optional. Knowledge transfer is not.
When not to migrate
If PE is paid, loved, and staffed, stay. If your code is a decade of unique snowflakes with no tests and no control repo, fix that first — on PE or OSS, the dumpster is the same shape.
Further reading
- Scaling Puppet Community — CA split and compiler VIP, still the blueprint.
- Puppet Primer series on questy.org — language fundamentals for the team inheriting the estate.
- SSCG pricing — health check, migration sprint, CMaaS, GUI standup.