OpenVox and Puppet Enterprise Migration

Choosing, or changing, your Puppet distribution

Since open-source Puppet stopped being maintained past 8.10 and Perforce moved ongoing development into the commercial Puppet Core line, teams running Puppet have a real platform decision to make, not just a version bump. Puppet Enterprise remains the fully supported commercial path, with its console, orchestrator, and RBAC. OpenVox is the community-maintained continuation of the open-source implementation, compatible with the Puppet language but distributed under different package names and repositories.

Both directions show up in practice: organizations moving from Puppet Enterprise to OpenVox to control licensing and stay open-source, and organizations moving from OpenVox (or unmaintained open-source Puppet) to Puppet Enterprise to get commercial support, console tooling, and RBAC. Some estates end up consolidating a mixed OpenVox/PE environment left over from a previous decision.

If the trigger is a Puppet 7-to-8 upgrade rather than a distribution change, see the Puppet 7 to 8 migration guide first — distribution choice and version upgrade are related but separate decisions.

What actually changes

• Packages and repositories. OpenVox and Puppet Enterprise ship under different package names, repository URLs, and installer paths. Existing install scripts, CI images, and provisioning code that hardcode Puppet Inc. or Perforce repositories need updating.
• Certificate Authority and agent trust. The CA can often be preserved across the migration, but this must be verified and tested, not assumed. A CA rebuild is a separate, riskier decision from the distribution change itself.
• PuppetDB and reporting. Compatibility between the PuppetDB version, the terminus, and the target Puppet Server/OpenVox Server build needs checking before cutover, not after.
• Console, RBAC, and orchestrator. Moving to OpenVox means losing the PE console, node classifier UI, and RBAC — that functionality has to be replaced with Hiera-driven classification, an external tool, or accepted as a deliberate trade-off. Moving to Puppet Enterprise means gaining them, with a migration of existing classification logic into the classifier.
• Module and Puppetfile compatibility. Most Puppet-language modules work unchanged, but anything depending on PE-specific facts, functions, or the orchestrator API needs review.
• Support model. Puppet Enterprise carries a commercial support agreement with Perforce. OpenVox support comes from the community and, where needed, from a consulting relationship like this one.

Delivery phases

1. Assessment: current distribution and version, module inventory, CA and certificate state, PuppetDB and reporting setup, console/RBAC usage if migrating away from PE, and any code that assumes a specific distribution.
2. Target design: package sources, CA continuity plan, replacement (or introduction) of classification and RBAC, and a rollback path that doesn’t depend on the migration succeeding.
3. Pilot: migrate a small, representative set of infrastructure and agent nodes; verify catalog compilation, certificate handling, and reporting end to end.
4. Staged rollout: move infrastructure components first, then agent cohorts, with explicit checks between each stage.
5. Verification and handover: confirm reports, PuppetDB queries, and (if applicable) console/RBAC behavior match expectations, and document the new operating model for the team.

What reduces migration risk

• Decide the distribution first, separately from any version upgrade that might be riding along with it.
• Test CA and certificate continuity in a non-production copy before touching real agents.
• Don’t discover console or RBAC dependencies during the cutover — inventory them up front.
• Keep a tested path back to the previous distribution until the new one has run through a full reporting and compliance cycle.