Migrating from Chef
Most Cinc projects are built from the same source as the corresponding Chef project, so migrating is usually a config-only operation. This page summarizes what to expect for each project and points at deeper walkthroughs.
How drop-in is “drop-in”?
| From | To | Effort |
|---|---|---|
| Chef Infra Client | Cinc Client | Minimal — install Cinc Client, point at the same Chef Infra Server; cookbooks unchanged |
| Chef Workstation | Cinc Workstation | Minimal — install Cinc Workstation, configs at ~/.cinc-workstation are compatible with ~/.chef-workstation |
| Chef InSpec | Cinc Auditor | Minimal — profiles are 100% compatible; inspec wrapper redirects to cinc-auditor |
| Chef Infra Server | Cinc Server | Moderate — requires a backup-and-restore using knife-ec-backup; nodes auto-reattach if FQDN is unchanged |
Cinc Client / Auditor / Workstation
For Client, Auditor, and Workstation, migration is essentially a reinstall:
- Uninstall the upstream Chef package on the target machine.
- Install the Cinc equivalent — see the Getting Started pages for one-liners.
- The Cinc binaries include wrappers for the upstream names (
chef-client,inspec,chef) that redirect to the Cinc equivalents, so existing automation keeps working. - Configuration paths are compatible — copy or symlink existing
client.rb,~/.chef-workstation, etc.
No data migration is required for the agents themselves: they’re stateless from the agent perspective. The state lives on the Chef / Cinc Server.
Cinc Server
Migrating a production Chef Infra Server to Cinc Server is more involved because all the cookbook, node, role, environment, and ACL data lives on the server itself. You’ll need to back up the source server and restore onto the destination.
The canonical walkthrough is in the “Migrating from Chef to Cinc” blog post by Carlos Aya. It covers:
- Standing up the destination Cinc Server
- Setting up a workstation machine for the backup
- Installing
knife-ec-backupandknife-tidy - Configuring source/destination knife profiles and trust
- Performing the backup, dry-run restore, and live restore
- Local and remote verification
- Re-pointing existing nodes (DNS swap or
client.rbupdate)
That post covers an RHEL 8 setup with a real production-sized dataset (~17 users, 63 environments, 481 roles, 539 cookbooks). The procedure works on other Linux distributions with appropriate package-manager substitutions.
Heads-up: upstream EOL
Progress has announced that the open source Chef Infra Server will reach end-of-life in November 2026 in favor of the proprietary Chef 360 platform. The Cinc Project intends to keep maintaining Cinc Server independently as a fork after that point — see the announcement post and the forking plan for details. If you’re considering a Chef → Cinc move for the server, doing it before the upstream EOL avoids needing to roll forward through a major version transition at the same time.
Going the other way
Cinc → Chef is also a drop-in for Client / Auditor / Workstation. For Server, the same knife-ec-backup procedure works in reverse — just swap source and destination.
Help
If you hit something unexpected, drop into #community-distros on the Chef Community Slack or file an issue on the relevant GitLab repo.