Why Puppet Enterprise 2023.8 end of support forces a decision now
Your Puppet Enterprise 2023.8 estate needs one decision before February 27, 2027: upgrade to a supported release on the Latest track, or move to OpenVox before that date. Maintenance for 2023.8 ended on August 27, 2026, so the time left is the support window that closes on February 27, 2027, and that date will not move. Plan against it for both paths, because moving agents, the primary server, certificates and the console takes longer than most teams expect, and it should not start in the final month.
The short answer is that an upgrade keeps you on Perforce's product, including the console, orchestrator and support contract, while OpenVox replaces the agent, server and OpenVoxDB with the community fork and leaves you to supply the console and orchestration yourself. OpenVox's install documentation describes 8.11 as functionally equivalent to Puppet, with the same command names and configuration paths, so the code-level change is smaller than the tooling change. Four factors should decide the path: how many nodes you manage, how much of your code depends on Enterprise-only features, how heavily operators rely on the console, RBAC and orchestration, and how many months your team can spend on the change. Large node counts, heavy console use and a short calendar favor the path that introduces the least new tooling. A smaller, code-heavy estate with spare engineering time has more room to choose.
Start with an inventory: count active nodes, list each Puppet Enterprise component in use (console, Code Manager, orchestrator, PuppetDB and any reporting you built on them), and separate forge modules from internal ones. Ask Perforce in writing which release the 2023.8 upgrade path lands on, what support terms apply, and what license the target requires. The Latest track gives each major version 12 months of full support, so expect to repeat major upgrades on roughly that cadence, which is a recurring cost. Compare that with the one-time migration work and the tooling you would run yourself under OpenVox. Set a decision date early enough that a failed trial still leaves time to fall back to the other path.
What the end-of-support deadline requires from your estate
Support for Puppet Enterprise 2023.8 LTS ends February 27, 2027, so each node class needs a supported platform, a rehearsed path onto it and a way back. The cards below set out the requirements that connect the upgrade and OpenVox options.
A supported platform before the deadline
Choose the target before the deadline: a current Puppet Enterprise version on the Latest track, which gives each major version 12 months of full support, or OpenVox. Either choice needs a dated plan that finishes before support ends. Confirm whether your Puppet Server, PuppetDB, console and agent versions all fall inside the supported window for your chosen target.
A complete inventory of versions
Record the exact Puppet Enterprise version and every agent version in use before choosing a path. Include primary and compile masters, PuppetDB nodes, Windows and macOS agents, and any nodes that run an older agent than the server. Note the operating system of each class, since the upgrade and migration steps differ by platform.
A rehearsed upgrade or migration path
Rehearse the chosen path on a staging copy of one node from each class. For OpenVox, the install guidance says Puppet and OpenVox cannot coexist, so each node must run the puppet-enterprise-uninstaller script before OpenVox packages are installed. Time the steps, record what breaks and repeat until the runbook is stable.
A tested rollback plan
Back up the whole /etc/puppetlabs tree on every node before any change, as the OpenVox install guidance strongly advises. Define the rollback trigger in advance, such as a failed catalog compile or an agent run that cannot reach the server, and rehearse restoring one node from its backup. Keep certificates and code under separate copies so a restore does not depend on a single source.
Evidence that each node class works
Run a test catalog for each node class and compare the results with the current estate. OpenVox 8.11 is functionally equivalent to Puppet, with the same command names and configuration paths, but that does not replace testing your own modules. Confirm that Puppet Enterprise features such as the console, orchestration and role-based access have a documented replacement for each team that uses them.
Ownership after cutover
Name an owner for patching, certificate renewals, backups and agent upgrades once Puppet Enterprise support ends. Decide who handles incidents on the new stack and who signs off on the cutover evidence. Record these owners and their handover in writing so audit and change records show a single accountable team.
Upgrade to Latest track or move to OpenVox: how each option meets the deadline
This table compares staying on Puppet Enterprise through the Latest track with moving nodes and servers to OpenVox before Puppet Enterprise 2023.8 support ends on February 27, 2027. Read each row against your node count, your use of Enterprise features and your migration calendar. The main takeaway: upgrading keeps the platform intact, while OpenVox removes the commercial dependency but makes you own the console, orchestration and support arrangements.
| Decision point | Upgrade to the Latest track | Move to OpenVox |
|---|---|---|
| How it meets the February 27, 2027 deadline | Move from 2023.8 to a current Latest track release before support ends. Confirm the supported upgrade path with Perforce. | Install OpenVox on every server and agent before support ends. Set your own cutover date well ahead of the deadline. |
| What stays the same | Puppet code, the Enterprise console, the orchestrator, RBAC and your Perforce support contract. | Language, command names and configuration paths. OpenVox 8.11 is documented as functionally equivalent to Puppet, and existing configuration files are kept. |
| What changes | Upgrade testing and a major-version cycle with 12 months of full support per major version. | Packages come from Vox Pupuli repositories. The PE uninstaller runs on each node, and OpenVox packages replace the Puppet packages. |
| Console, orchestration and RBAC | Remain available as part of Enterprise, with no replacement needed. | The Enterprise console and orchestrator must be replaced. Confirm how you will meet your RBAC and audit requirements. |
| Support and accountability | Vendor support comes from Perforce under your existing contract. | Maintained by the Vox Pupuli community under CC BY-SA 4.0 and Apache 2.0. Any paid support must be arranged separately. |
| Compatibility over time | Depends on Perforce's release and licensing decisions for each major version. | OpenVox aims to stay compatible with downstream Puppet for as long as it can. Treat this as a project goal, not a guarantee. |
| Main trade-off | Lowest operational change, but keeps the commercial license and its renewal terms. | Ends the dependency on Enterprise packages, but adds migration work and makes you responsible for support. |
| Choose this option when | Enterprise console, orchestration and vendor support are central to operations and the license terms suit you. | Your team can run the replacement tooling and support, and a non-production pilot confirms your modules work. |
What the Latest track upgrade keeps and what it postpones
Staying on Puppet Enterprise keeps everything the commercial product provides: the console, orchestration, role-based access control and vendor support. On the Latest track, each major version receives 12 months of full support, so the decision turns on when the next major upgrade arrives. For a 2023.8 installation, maintenance ends on August 27, 2026 and support ends on February 27, 2027, so the upgrade must land before those dates whichever path you choose. Treat the upgrade as a recurring program, because each new major version starts another 12-month full support window and the work repeats for as long as you remain on Puppet Enterprise.
The trade-off is continued dependence on Perforce's Puppet packaging and terms. Since 2025, Puppet packages have been distributed from a private repository under a EULA, so your upgrade path, package access and licensing for your node count are set by the vendor, not by your own change calendar. Before committing, ask Perforce to confirm in writing the exact supported upgrade path from 2023.8 to the Latest track release you would target, which licensing applies to your node count, and what happens to package access if the agreement changes. Those written answers determine whether each future major upgrade is a cost you can plan for.
Before that conversation, inventory what your environment depends on: console role assignments, orchestration jobs, code deployment workflows, and any Puppet Enterprise-specific modules or settings. These dependencies decide how much of each upgrade is testing effort. Ask Perforce for a written statement of the support end date for the target version, so the upgrade window goes into your change calendar with a fixed deadline. Keep the inventory and the vendor answers together, so the same questions can be put to the OpenVox path on equal terms.
How to move from Puppet Enterprise 2023.8 to OpenVox before the deadline
This sequence takes each Puppet Enterprise node through a backup, a clean removal of the Enterprise packages, an OpenVox install and a validated return to service, with a pilot and a rollback path before the cutover.
Inventory nodes and confirm the target version
The platform team lists every Puppet Enterprise server, compile master, agent and OpenVoxDB node, along with its operating system and the modules and Hiera data it depends on. Confirm the OpenVox release to install on the Vox Pupuli GitHub releases page at github.com/OpenVoxProject/openvox/releases, because the newest release, 9.1.0, is later than the 8.11 release that the install documentation describes as functionally equivalent to Puppet. Record the chosen version in the change plan. The step is done when every node has an owner, an operating system and a target OpenVox version written down.
Back up the whole /etc/puppetlabs tree
On each node, the administrator copies the entire /etc/puppetlabs directory to storage outside the node, including certificates, the CA directory, puppet.conf and the code directory. The OpenVox install documentation strongly advises this backup before any package change. Store the copy with restricted permissions because it contains private keys. The step is done when the archive's checksum has been recorded and a test restore has been read back on a separate host.
Pilot the change on non-production nodes
The team runs the full sequence on a small set of non-production agents and one non-production server, including a compile master if you use one. It checks that catalogs compile, that agents report to the server and that the modules and Hiera lookups return the same values as before. Record any differences in module behavior or help text for the production runbook. The step is done when a pilot server and its agents complete a clean Puppet run and the team signs off on the results.
Remove Puppet Enterprise packages with the uninstaller
On each node, the administrator runs the puppet-enterprise-uninstaller script before installing any OpenVox packages, because the documentation requires it for Puppet Enterprise nodes. Puppet and OpenVox cannot be installed on the same system, so this step must finish before the next. Confirm that the Puppet services have stopped and that the Puppet packages are no longer listed by the package manager. The step is done when the node reports no Puppet Enterprise services or packages.
Install OpenVox from the Vox Pupuli repositories
The administrator enables the openvox8-release repository package from apt.voxpupuli.org or yum.voxpupuli.org, then installs openvox-agent on all nodes, and openvox-server, openvoxdb, openvoxdb-termini and openbolt on the server and PuppetDB tiers. OpenVox packages replace legacy Puppet packages and keep existing configuration files. Pin the version confirmed in the first step. The step is done when
puppet --versionon each node reports the chosen OpenVox release and the services start without configuration errors.Validate configuration and certificates
Because existing configuration files are kept, the team checks puppet.conf, the Hiera configuration, the environment definitions and the certificate setup against the backup. It runs a configuration check, requests a test certificate for a pilot agent and confirms that the server trusts it. It also tests a full catalog run and a query against OpenVoxDB. Record the outputs. The step is done when the pilot agent completes a signed run against the OpenVox server and OpenVoxDB returns data.
Replace the console and orchestrator separately
The OpenVox packages do not provide the Puppet Enterprise console or orchestrator, so the team decides how reporting, role-based access and job orchestration will work after cutover. Options include a self-hosted dashboard, scheduled OpenBolt tasks and existing ticketing or CI workflows. Ask any vendor to confirm which features it covers before you plan around it. The step is done when each Enterprise feature in use has a named replacement and an owner.
Roll back to the backup if validation fails
If a node fails validation, the administrator removes the OpenVox packages, restores the /etc/puppetlabs archive from the first step and reinstalls the Puppet Enterprise packages from the original media or repository still available to the organization. Confirm that the node returns to a clean Puppet run before any other change. Keep the rollback procedure rehearsed on the pilot nodes so it is known to work. The step is done when a rolled-back node completes a successful run against the original server.
What evidence the migration or upgrade should produce
A CISO or auditor will want proof that the change was planned, tested and reversible, not only that it finished. The items below connect the backup, the node inventory, the pilot results and the decision record into one trail that can be reviewed after the Puppet Enterprise 2023.8 LTS end of support date. DeployOpen prepares this evidence but does not issue audit reports or certifications.
Pre-change backup and restore test
A copy of the whole /etc/puppetlabs tree, taken before any uninstaller or install step runs, with the checksum recorded and the storage location documented. The evidence that matters is a restore test: the backup is restored to a scratch host, the Puppet configuration is read back, and the result is written down. Ask the team to show who holds the backup, how long it is retained and where the restore was tested. Upgrade and replacement both depend on this record.
Node and agent version inventory
A list of every managed node, its operating system, its current Puppet agent version and its role, captured before the change and again after it. The two snapshots show which nodes moved, which were skipped and which remain on older agents. Any node missing from the second list needs an explanation. Ask for the inventory source, such as PuppetDB queries or a CMDB export, so the auditor can trust the completeness of the list.
Change records for each node
Per-node change tickets that log the run of the puppet-enterprise-uninstaller script on Puppet Enterprise hosts, the OpenVox installation, the time window, the operator and the outcome. Installing OpenVox on a host with Puppet Enterprise still present is not an option, so the uninstall step is the change that most needs a traceable record. Ask whether each ticket links back to the backup and inventory entries for the same node.
Pilot catalog compile and agent run results
Output from a pilot group showing that catalogs compile on the new server and that agents complete a run without failed resources. Keep the compile logs, the agent run reports and a list of any resources that changed unexpectedly. Compare results against the production code and modules, since language differences surface here first. Ask for pass and fail counts per environment rather than a single summary line.
Upgrade or replacement decision record
A written record that compares staying on the Latest track of Puppet Enterprise with moving to OpenVox, covering support dates, licensing, module compatibility, console and orchestration needs, and the people who own each risk. The record should name the approver and the date of approval. Auditors read this document to confirm that the choice was deliberate and that the reasons match the facts available at the time.
Rollback test result
Evidence that the rollback path was exercised on a test node before cut-over, including the time taken to return a node to its previous state and the checks run afterward. A rollback plan that has never been run is a plan, not a control. Ask whether the test used the same backup described above and whether any step required manual repair. The result should state what was restored, what was not, and who signed off.
Questions teams ask before the Puppet Enterprise 2023.8 deadline
What does it cost to move off Puppet Enterprise 2023.8?
The main cost is labor and infrastructure, not the OpenVox packages, which are free to download. Puppet Enterprise and Puppet Core licenses are quoted by Perforce, so compare them against the renewal or upgrade quote you already hold. Cost components to price separately:
- Servers and PostgreSQL behind OpenVoxDB, which recur as infrastructure.
- A replacement for the Puppet Enterprise console and orchestrator, which is often a one-time build with ongoing operation.
- Migration engineering, testing and cutover, which are one-time.
- Support you arrange yourself, which recurs.
Node count, custom modules and how much your team relies on console features drive the total up or down. Ask any provider for a quote that lists each component, the assumptions behind it, and what is excluded.
How long does a Puppet Enterprise to OpenVox migration take?
The duration depends on your environment, not on a fixed figure we can give here. The biggest drivers are the number of nodes and server environments, how complex your control repository and module dependencies are, how much test coverage exists, and how many change windows you can use. Console and orchestrator replacement often adds more time than the agent and server move itself. Perforce's published dates are that maintenance for 2023.8 ended August 27, 2026 and support ends February 27, 2027, so work back from the support end date and plan a staging run before any production window. Ask for a timeline in the written scope, with milestones and the assumptions behind each one.
What does our internal team need to provide during the migration?
Your team needs to supply access, decisions and sign-off that an outside party cannot make alone. Plan for:
- Change windows on each affected environment, including a rollback window.
- Root or administrative access to each Puppet node, because the uninstaller runs on every node.
- Certificate authority owners who can confirm how agent certificates and the CA will carry over.
- Code and control repository owners who can confirm module versions and environment mappings.
- Owners for the Puppet Enterprise console and RBAC model, who will define what replaces them.
- Someone accountable for backing up the whole /etc/puppetlabs tree before any change.
Name these owners in the scope document before work starts so approvals do not stall the schedule.
Can our own team migrate using the OpenVox install documentation?
Yes, a team with Puppet administration skills can follow the OpenVox install documentation, and many do. The documented sequence is to back up /etc/puppetlabs, run the puppet-enterprise-uninstaller on each node, enable the openvox8-release repository package from apt.voxpupuli.org or yum.voxpupuli.org, and install openvox-agent, openvox-server, openvoxdb, openvoxdb-termini and openbolt. Puppet and OpenVox cannot coexist on one system, so each node changes in place. The documentation does not cover replacing the console, orchestration or RBAC, which you must design yourself. Decide early whether your team has the time, the test coverage and the on-call capacity to carry the change, and where outside help would reduce risk.
Is OpenVox compatible with our existing Puppet code and modules?
OpenVox 8.11 is described in its install documentation as functionally equivalent to Puppet, with the same command names and configuration paths, and the differences are mainly in help text and man pages. The project aims to stay compatible with downstream Puppet for as long as it can, and a Puppet Standards Steering Committee guides language and feature direction. Compatibility still needs testing against your code. Check your module versions, any Puppet Enterprise-only functions or modules, and the features you use through the console and orchestrator, since those are not part of the OpenVox package set. Run your full control repository against a staging OpenVox server before any production node changes.
Is upgrading to the Latest track the lower-risk choice?
Upgrading keeps you on a Perforce-supported product with the console, orchestration and support you already use, so it avoids replacing those parts at once. Perforce's Latest track gives each major version 12 months of full support, which means you would plan a major upgrade about once a year to stay supported. The trade-offs are continued dependence on Perforce licensing and a recurring upgrade cycle. Moving to OpenVox removes that dependence but puts the console, orchestration and support arrangements on your side. Neither choice is lower risk in every environment. Compare the licensing terms, the upgrade effort per cycle and your team's capacity before deciding, and document the reasoning for your change board.
How DeployOpen works on this
DeployOpen starts by confirming which Puppet Enterprise 2023.8 LTS nodes, servers and integrations are in scope, then decides with you whether to upgrade on the Latest track or move to OpenVox before the deadline. The work is planned, built, tested and documented inside your own infrastructure, with a written scope agreed before any change is made.
How we scope
- We inventory every PE server, compile master, agent, console and orchestrator role, with the node count and the module code each one depends on.
- We map your Hiera data, custom modules, external facts and reporting integrations to confirm which ones OpenVox must run unchanged.
- We agree a fixed scope in writing covering the upgrade or migration path, the cutover approach, and the deliverables for Puppet Enterprise 2023.8 LTS end of support.
How we build
- We build a staging copy of the Puppet environment, back up the whole /etc/puppetlabs tree and rehearse the PE uninstaller on each node before any production change.
- We install openvox-server, OpenVoxDB, openvox-agent and OpenBolt from the Vox Pupuli repositories, then test catalog compilation and agent runs against your existing code.
- We harden the servers, configure certificate handling and secrets, and test the replacement for the PE console and orchestrator against the access controls you need.
How we hand over
- We document the target architecture, runbooks for upgrades and rollback, and the configuration changes made on each role.
- We provide evidence of backups, test results and cutover checks, prepared so your own auditors can review them. DeployOpen does not issue audit reports or certifications.
- We walk your platform and operations teams through day-to-day running of OpenVox, so ownership transfers to your staff at the end of the engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped separately from the migration.
- Ask any quote to separate one-time migration work from recurring retainer work, so you can see which costs repeat each year.
- Confirm with your team which parts you want DeployOpen to run after go-live and which you will keep in-house, and record that split in the written scope.
