Start with what this is not. SwitchTender is not a configuration management engine. It has no resource model, it does not converge state, and your cookbooks do not convert. Nothing here will read a recipe and produce a working equivalent, and anything that claimed to would hand you something that reads like the original and behaves differently. What SwitchTender takes is the fleet: every node, grouped by its environment and by every role in its run list, governed and audited from the day it lands, while you deal with the recipes on your own schedule.
Chef moved to commercial licensing under Progress, and the open source line no longer has a supported path forward. That leaves a large installed base in a specific position: the machines are still there, still grouped by environment and run list, still doing their jobs, and the thing that manages them is no longer somewhere you can stay for free.
This is a different problem from the one AWX users have. AWX went quiet, and quiet is something you can ignore for years. A licensing change is not quiet. It arrives with a renewal conversation attached.
Said plainly, because the useful version of this page is the one that does not waste your afternoon.
knife node list | xargs -I{} knife node show {} -F json > chef-nodes.json
switchtender import chef chef-nodes.jsonEvery node becomes a host. Its chef_environment becomes a group, and every role[...] in its run list becomes a group as well, so a play can target [webserver] on the day of the import rather than after somebody rebuilds the grouping by hand. The ohai facts that identify a machine come across as host variables, and ipaddress is also set as ansible_host, because a Chef estate addresses machines by node name and has no reason to have kept DNS in step.
The preview runs before anything is created, and it names what it left behind: every recipe it saw, and every field in the export this importer does not read. A clean report means clean, which is the only way a report is worth reading.
Because the fleet is the part that transfers honestly, and it is the part you need first. The moment those nodes are in SwitchTender, every command run against them goes through one path: request, policy, approval. Each run leaves a signed receipt that verifies offline without us. You get an audited record of everything done to those machines during the migration, which is exactly the window where an estate is touched most and recorded least.
The recipes can then be rewritten at whatever pace the work actually takes, against a fleet that is already governed rather than one nobody is watching.
The three asked most often when somebody is comparing this against what they already run.
No. It reaches the machines it manages over SSH, the same way Ansible does, and installs nothing on them. There is no per-host daemon to deploy, patch, or account for. You run the one server binary. Worker processes for extra throughput are a Team feature, and they are pool members rather than agents belonging to a host.
All three, resolved at launch rather than copied into this database. Vault dynamic secrets go further: a short-lived credential is minted for each run and revoked when the run ends. AWS and Azure both authenticate from an instance role or managed identity with no stored key, and anything else resolves through a command whose output is the secret.
Yes, and it is what pipelines are for here. Steps mix tools freely on a dependency graph with parallel branches, built on a drag-and-drop canvas. The approval is not a convention somebody can skip: a policy decides which runs are held, the core enforces the hold, and the approval binds to the exact plan reviewed, so a run cannot be approved as one thing and executed as another.