Puppet Support, Upgrades & OpenVox Migration
Last reviewed by Tyler Eastridge
AceMQ gives enterprise teams 24/7 engineering support for Puppet Server, PuppetDB and agents, plans upgrades between Puppet versions, and tests and plans a move to OpenVox, the community fork, or to another tool. AceMQ engineers lead each engagement and partner automation specialists do the Puppet-specific work, under one AceMQ contract. AceMQ gives no Perforce licensing advice, builds no OpenVox packages and does not rewrite manifests.
A senior engineer, not an SDR. No sales sequence attached.
Without a rewrite or a rushed licensing decisionFor production incident cover, see AceMQ Puppet 24/7 support.
Customers
Partners
The Problem
Eight Puppet problems, from licence terms nobody has read to a compile pool that fails for part of the fleet mid-upgrade. AceMQ starts on whichever one is costing you failed runs.
Perforce now develops Puppet Core 8 and 9 as a proprietary product and nobody on the team has read what that means for the binaries in use
Puppet 7 reached end of life in April 2025 and part of the fleet is still on it
A Puppet Server upgrade starts in one compiler and agents sent to it begin failing their runs
Catalog compile times creep up until a JRuby pool is exhausted at peak check-in
PuppetDB grows without limit and reports are kept far longer than anyone reads them
Agent run failures are reported to a console that no one watches, so drift builds quietly
The one engineer who understands the module layout and the r10k pipeline is leaving
Someone has proposed moving everything to Ansible and nobody has counted what a rewrite would cost
A good fit if you run Puppet in production and need a plan for the 2026 licence change, engineers on call for the servers, or a written view of run failures and compile times before the next upgrade.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Puppet.
How it breaks, and the fix
Puppet Server pools are upgraded one compiler at a time, so for a while two versions answer the same agents. A module that compiles on the old version can fail on the new one, and the agents sent to it stop applying changes.
Mixed-version pool, one compiler failing
One code deployment, two compilers, the catalog and the agents
Both compilers run the same version and compile catalogs from the same code. Agents check in, apply changes and report success.
Compiler 2 is upgraded first. A module relies on behaviour the new version rejects, so catalogs compiled there fail. The load balancer keeps sending a share of agents to it, and their runs fail while the reports go unread.
The target version is run against the real control repo in a staging pool first. Failing modules are fixed or pinned, and the upgrade then moves through the pool in rings, with run failures watched at each step.
The upgrade question and the licence question look separate and are not. Whichever route a team picks, it ends at the same place: a Puppet Server version running your code. Moving to a newer Perforce release, moving from Puppet 7, which Perforce lists as end of life since April 2025, or moving to OpenVox all come down to compiling real catalogs from real modules and watching agent run failures, compile times and PuppetDB health while the pool is mixed. Perforce also moves to a Latest and Latest-1 support model from Puppet Enterprise 2026.0, so the version you run has a shorter shelf life than the older long-term releases. A written test of the target against your own code, with the findings ranked, is the first AceMQ deliverable.
Our Services
AceMQ runs five Puppet service lines: an OpenVox migration assessment, Puppet Server and PuppetDB operations, upgrade planning, a stay, fork or exit review, and a fixed-scope health check. Each ends in a written deliverable, and on-call cover with a 15-minute emergency SLA can be added to any of them. Converting manifests to another tool is not on the list.
A test of your own modules, agents, Puppet Server and PuppetDB against OpenVox, with a ring-by-ring plan, before anyone commits.
Engineers on a bridge when compilers are slow or down, agents fail their runs or PuppetDB falls behind.
A plan from the version you run to one that is still supported, with compilers upgraded in order and agents in rings.
A written comparison of staying on Perforce's Puppet, moving to OpenVox and moving to another tool, using your own estate's numbers.
The fixed-scope entry engagement: a written report on the state of the servers and the code that your own team can act on, with or without AceMQ afterwards.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ Puppet support gives you an AceMQ engineer and a 15-minute first response when agents stop converging or a Puppet Server pool is down, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Perforce support and subscriptions stay with Perforce: AceMQ does not provide them.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ Puppet engagement runs in four stages: a scoping call with a quote within 1 hour, a read-only review of your servers, code and run reports, a written recommendation on staying, forking or leaving, then staged changes and on-call. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: Puppet Core or Enterprise and the versions, how many nodes and compilers, how code is deployed, who is on call and what is driving the question. A quote request is answered within 1 hour.
Scoped per estate
A review of Puppet Server and PuppetDB health, run reports, compile times, certificates, module versions and the deployment pipeline. Nothing in production changes, and the findings are written and ranked by risk.
Scoped per estate
A written recommendation on staying, moving to OpenVox or leaving Puppet, with the tests behind it and the dates that apply. Support cover starts here if you want it.
Ongoing
Upgrades or migration in rings with the old servers kept as the rollback, and on-call response with a 15-minute P1 SLA. A written review follows every upgrade window or incident.
A senior engineer, not an SDR. No sales sequence attached.
What changed
Several separate events landed within two years, and they are easy to run together. This is each one with the date it took effect and where it was published, as of 4 November 2026. What they mean for your own agreement is between you and Perforce.
Apr 2025
Perforce's release notes say that, as of April 2025, open source Puppet 7 and Puppet Core 7 are end of life. A node still on 7 is out of the vendor's support.
Aug 2026
The same release notes say that, as of August 2026, Perforce develops and supports Puppet Core versions 8 and 9 as a proprietary product. AceMQ gives no licensing advice: read the terms that apply to the binaries you download.
3 Nov 2026
OpenVox, a community fork of Puppet, published 9.3.0 and 8.32.0 on 3 November 2026 on GitHub. Whether it suits your estate is a question for a test on your own modules, not for a headline.
2027 to 2029
Puppet Enterprise 2023.8.z reaches end of maintenance and support on 27 February 2027. Puppet Core 8 reaches end of life in February 2028 and Core 9 in February 2029, with the Core 9 dates marked projected by Perforce.
Typical engagements
Typical engagements from AceMQ on the platforms around Puppet, with the environment, what AceMQ assesses and what the engagement delivers. Each card links to the full write-up.
Solutions
AceMQ covers Puppet end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Puppet on your infrastructure and fully managed Puppet on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Puppet for you.
Compare the four Puppet support tiersSide by side
Three routes are open to a Puppet estate after the 2026 licence change, and AceMQ works with all three. This table compares what each one changes for the team that runs it, not which is best. AceMQ is not a rewrite service: manifests are not converted to playbooks.
| Question | Stay on Perforce's Puppet | Move to OpenVox | Move to Ansible or another tool |
|---|---|---|---|
| Who builds and supports it? | Perforce. Its release notes say Perforce develops and supports Puppet Core 8 and 9 as a proprietary product as of August 2026. Puppet Enterprise is sold under subscription. | A community fork of Puppet, released from the OpenVox project on GitHub. Releases 9.3.0 and 8.32.0 were published on 3 November 2026. | Red Hat and the Ansible community for Ansible. Other tools have their own vendors. |
| What changes in your code? | Nothing. Manifests, Hiera data and modules stay as they are. | The aim is to keep modules working. AceMQ tests your own modules, Puppet Server and PuppetDB against it in a staging pool rather than assuming it. | Everything. Manifests, Hiera data and modules are re-expressed as playbooks and roles, which is a rewrite. |
| Which dates matter? | Puppet Core 8 reaches end of life in February 2028 and Core 9 in February 2029 (Core 9 dates are projected). Puppet Enterprise 2023.8.z reaches end of maintenance and support on 27 February 2027. | Its releases page lists no end-of-life dates. Judge it by release cadence and by who supports it for you. | ansible-core maintains three versions at a time, so the calendar moves every six months. |
| Where does AceMQ help? | Upgrades between Puppet versions, operating the servers, and engineers on call next to Perforce support. | A compatibility test, a ring-by-ring cutover plan, and engineers on call for the OpenVox servers. | Planning the order the estate moves in, running both tools in parallel, and keeping the Puppet servers up until the last node has moved. |
| When does it fit? | You have a Perforce agreement you are content with, and the terms of the binaries you download are clear to you. | You want to stay on Puppet's model and keep your code, and you accept running a community project. | You were already planning to leave Puppet, or you manage few enough node types for a rewrite to pay. |
For the dates, the licence wording and the alternatives in more detail, read Puppet alternatives after the Perforce licence change.
One partner, not five
Puppet rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on support windows across open-source tools, plus the AceMQ services around Puppet: Kubernetes, Docker, monitoring and PostgreSQL.
FAQs
Five answers on Puppet from AceMQ: whether to stay on Puppet, what OpenVox is, whether it is a drop-in replacement, what AceMQ does next to Perforce support, and what is out of scope.
Still have questions about Puppet? Email an Expert
No. Perforce's release notes say it develops and supports Puppet Core 8 and 9 as a proprietary product from August 2026, and Puppet 7 is end of life. Many teams will stay. What the change means for you depends on your Perforce agreement and the binaries you use, and AceMQ gives no licensing advice. AceMQ's part is the engineering: a recommendation on staying, forking or leaving, backed by tests on your own code.
OpenVox is a community fork of Puppet, published from the OpenVox project on GitHub. Its releases page showed 9.3.0 and 8.32.0 on 3 November 2026. AceMQ does not build or ship its packages, and it is not affiliated with the project. AceMQ tests it against your modules and operates the servers.
Treat it as a candidate to be tested, not a guarantee. AceMQ builds a staging pool from your control repo, runs your modules, agents, Puppet Server and PuppetDB against OpenVox, and writes up what works and what does not before any production node moves.
Yes. AceMQ supplies engineers who operate the servers, diagnose failing runs and plan upgrades, with a 15-minute emergency response and 24/7 cover. Fixes, builds and subscriptions that Perforce provides stay with Perforce, and AceMQ does not provide them.
No. Code rewrites are outside AceMQ's scope. AceMQ can count what a rewrite would involve, plan the order the estate moves in, run both tools in parallel and keep the Puppet servers up until the last node has moved.
Yes. AceMQ works on Puppet in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Puppet environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Puppet is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Puppet estate, tells you what cover or migration plan fits, and quotes it. Quote requests are answered within 1 hour.
Production incident right now?Email a Puppet Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
