morten/nordbye.it

client · case study

Puppet to Ansible Migration

Replaced a long-standing Puppet estate with idempotent Ansible roles, moving the customer off a tool their hosting provider was sunsetting while running a parallel RHEL7-to-RHEL8/9 redeploy of the application fleet at the same time.

All work
Role
IT automation consultant
Client
Confidential SaaS provider (20+ years in market)
Period
2023 - 2024

Stack

  • Ansible
  • GitLab
  • Postfix

results

What shipped.

  • /01

    Puppet-managed servers progressively replaced by Ansible-driven equivalents, including mail and several other critical systems.

  • /02

    Lower complexity from the agentless architecture, removing an entire class of moving parts.

  • /03

    Better integration with the customer's existing DevOps toolchain.

  • /04

    Faster, more predictable rebuilds when servers need replacing.

architecture

How it fits together.

Hover a node to highlight its connections. Click one to read what it does and why it is there.

Managed estatemigratedexternalEngineersgitopsGitLab CIlegacyPuppet master — legacygitopsAnsiblecomputeMail servers (Postfix)computeOther critical systemsobservabilityDrift checks

The brief

A SaaS provider with two decades of operating history had its infrastructure configured almost entirely with Puppet. Their hosting provider was phasing out Puppet support, so the estate had to move to something that would be supported long-term. They picked Ansible.

What I did

I wrote all Ansible roles solo. Mail servers (Postfix), application servers, the jump-host and Postgres servers were all rebuilt against the new automation. Rollouts were set up so the customer could compare old and new side by side before switching traffic.

Most of the actual work was at the seams.

  • Translating the Puppet resource model into idempotent Ansible tasks that produce the same end state without surprising the people running them.
  • Standardising role layout and inventory so future engineers can find their way around quickly.
  • Running deploys through Jenkins on every change, with roles stored in GitLab on-prem, to catch drift early and keep the delivery pipeline auditable.

In parallel with the config-management work, the application server fleet was redeployed RHEL7 to RHEL8/9 via blue-green, the same low-risk pattern used on the transport-sector Kubernetes migration the year before. Both sides run in parallel; traffic flips only when the new side is verified. The two tracks ran concurrently through the engagement.

Why it mattered

Two large migrations ran in parallel (Puppet to Ansible and a RHEL major redeploy) and both completed without incidents. Configuration management is rarely the headline, but it is the layer everything else relies on, and replacing it while keeping production running is most of the job.