Ansible Deprecated Module to FQCN Migration Prompt
Convert short module names and deprecated syntax to fully-qualified collection names and current parameters, with a per-change rationale and verification plan.
- Target user
- Ansible engineers clearing deprecation warnings before a major-version upgrade
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior automation engineer who has migrated large playbook estates onto fully-qualified collection names (FQCN) and cleared deprecation warnings ahead of major ansible-core upgrades. You know which short names map to which collection and which renamed parameters changed behavior, not just spelling. I will paste playbooks/roles and (optionally) the deprecation warnings from a run. Your job is to produce a precise migration to FQCN and current syntax, change by change, that I can review before applying. Steps: 1. **Map every short module name to its FQCN**: e.g. `yum`/`apt`/`service`/`copy`/`template` to their `ansible.builtin.*` form, and community/galaxy modules to their owning collection. If a module moved or was renamed, say so and give the new name. 2. **Flag deprecated modules with replacements**: where a module is deprecated in favor of another (not just renamed), explain the replacement and any behavioral difference. 3. **Fix deprecated parameters and warn-level syntax**: renamed args, removed args, `warn:` on command/shell, bare variables in `when`, and other items the run flagged. 4. **List required collections**: produce the `collections` entries / `requirements.yml` additions needed so the FQCN names resolve, with version pins where a parameter depends on a minimum version. 5. **Rationale per change**: for each edit give a one-line reason (pure rename vs behavioral change vs removed-in-next-major). Fill in: - Files to migrate: [PASTE OR LIST PATHS + CONTENT] - Deprecation warnings from the run, if any: [PASTE] - Target ansible-core version: [e.g. 2.17] - Collections already installed: [LIST OR "unknown"] Output format: a unified-diff-style block per file showing only the changed lines, then a `requirements.yml` snippet for any new collections, then a verification checklist (run `ansible-lint`, run `--syntax-check`, run `--check --diff` on one host, confirm zero deprecation warnings). Separate pure renames from behavioral changes in a short summary. Do not apply the changes or run the playbook for real. Behavioral-change edits must be called out explicitly so I review them before any run on managed hosts.
Why this prompt works
Deprecation cleanups go wrong when someone bulk-replaces short names and ships it, not realizing a couple of those “renames” were actually behavioral replacements or depended on a collection that isn’t pinned. The prompt forces the model to separate pure renames from behavioral changes and to emit the matching requirements.yml entries, so the FQCN names actually resolve at run time instead of failing with “couldn’t resolve module.”
Asking for a unified-diff per file keeps the change set small and reviewable. You see exactly which lines move, with a one-line reason each, rather than a regenerated role you have to diff yourself. That rationale column is what lets you fast-track the trivial renames and slow down on the handful that change behavior.
The verification checklist closes the loop with the tools that actually prove the migration: --syntax-check and ansible-lint catch resolution errors, and a single-host --check --diff confirms the renamed parameters still produce the same intended state before you touch the fleet.