Introduction

An automation migration can publish a new execution environment in Ansible Automation Controller while job templates still run against the old one. Jobs launch and even succeed, but they use outdated collections, Python dependencies, or registry trust, one template picks the new environment while another still inherits the previous image, or failures begin only after the old image or registry is removed because template bindings, organization defaults, and controller settings often change separately.

Treat this as an execution-context problem instead of a generic Ansible outage. Start by checking which execution environment an affected job template actually launches with, because migrations often validate the new image in the controller UI while scheduled jobs continue inheriting older defaults.

Symptoms

  • Ansible Automation Controller still runs jobs against the old execution environment after migration
  • Jobs start successfully, but they use outdated collections, Python modules, or trust settings
  • One job template uses the new environment while another still inherits the previous one
  • Failures begin only after the old image, registry, or credential is removed
  • The new execution environment exists, but migrated jobs never use it
  • The issue started after moving Automation Controller, execution environments, or private registry configuration

Common Causes

  • The job template still binds directly to the old execution environment
  • Organization, project, or controller defaults were updated in one place but not another
  • Schedules or workflow templates still launch older job templates that reference the retired environment
  • Registry credentials or image pull trust were updated, but template bindings were not
  • Automation-as-code or controller import jobs keep restoring the previous execution environment association
  • Validation confirmed the new execution environment could run manually but did not verify what scheduled or inherited jobs actually used

Step-by-Step Fix

  1. Capture one affected job run and record the job template, workflow, execution environment, and organization defaults it actually uses, because the live execution context determines which dependencies and trust settings the job really inherits.
  2. Compare that active job path with the intended post-migration controller design, because one stale template binding can keep whole automation flows tied to the retired environment.
  3. Review job templates, workflow templates, schedules, organization defaults, controller settings, and automation-as-code definitions for references to the old execution environment, because Automation Controller inheritance can come from multiple layers.
  4. Check manually launched jobs and scheduled jobs separately if behavior differs, because migrations often update the visible template while an older workflow or schedule still calls the previous definition.
  5. Update the authoritative execution environment binding and inherited defaults so affected jobs launch with the intended image, because publishing the new environment alone does not retarget existing templates.
  6. Run a controlled job and confirm the intended execution environment image, dependency set, and registry path are the ones actually used, because a successful job run does not prove the right environment handled it.
  7. Verify the old execution environment image no longer receives pulls or job launches from migrated templates, because split automation paths can remain hidden while both images stay available.
  8. Review registry credentials, image policy, and collection compatibility if jobs still fail, because the destination can be correct while trust or dependency differences still block the new path.
  9. Document which team owns controller templates, execution environment publishing, and migration validation so future automation cutovers verify the actual runtime execution context before retiring the previous image.