Don't Rewrite Everything
You join a company with 50,000 lines of Puppet code managing their web servers. They want to move to Terraform and Immutable Infrastructure. Your instinct might be to rewrite all of it. Resist that instinct.
Those 50,000 lines encode years of institutional knowledge: security hardening rules, compliance baselines, performance tuning, edge cases discovered through production incidents. Rewriting them from scratch means rediscovering all of those lessons the hard way.
The "Bake-In" Strategy
The bridge between legacy CM and modern immutable infrastructure is HashiCorp Packer. Packer is a tool that automates the creation of machine images (AMIs on AWS, snapshots on GCP, etc.) by launching a temporary server, configuring it, and saving the result as an image.
Critically, Packer supports provisioners — including chef-solo, puppet-masterless, and salt-masterless. This means you can run your existing CM code at image build time rather than at runtime.
The workflow:
A Packer template for this pattern launches a base image, runs the existing Puppet manifests against it in masterless mode (no live Puppet Master required), and finishes with one more provisioner step that disables and removes the Puppet agent from the image before it's saved. In an immutable setup, you never want the agent running on production servers — it would try to contact a Master that may not exist, and more importantly, it would attempt to make changes to a server that should never change.
What Changes in Your Workflow
| Concern | Legacy (Mutable) | Modern (Immutable) |
|---|---|---|
| When CM runs | Every 30 min on live servers | Once, during Packer build |
| CM Master | Required, always running | Not needed (masterless mode) |
| Config changes | Push new code → agents converge | Build new AMI → roll ASG |
| Rollback | Re-run previous CM version | Launch previous AMI version |
| Audit trail | CM run reports | AMI version history + CI/CD logs |
Interviewers at companies modernizing legacy infrastructure often ask: "How would you migrate from Chef/Puppet to an immutable infrastructure model without a full rewrite?" The answer is the Packer bridge pattern: use chef-solo or puppet-masterless as a Packer provisioner to bake existing CM code into AMIs. This gives you immutable deployments immediately while preserving the existing configuration logic. The rewrite can happen incrementally over months as individual components are migrated to Dockerfile, cloud-init, or Ansible.
Key Point: The Packer bridge pattern is not a permanent destination — it is a migration vehicle. The goal is to eventually replace the CM code with simpler, purpose-built tooling (Dockerfiles for application config, Terraform for infrastructure, cloud-init for basic bootstrapping). But it lets you adopt immutable infrastructure patterns on a timeline of weeks rather than years.