Migrate from Ansible Automation Platform to Semaphore UI

Migrate from Ansible Automation Platform to Semaphore UI: what it involves

Moving from Ansible Automation Platform to Semaphore UI is a rebuild of objects and access rules, not a database copy. Semaphore UI stores its own projects, inventories, key stores, templates, schedules and users, so the work is recreating what automation controller held and deciding how each piece maps across. Teams usually take on this work because of a renewal, a licensing change or a data residency requirement, and the work is typically carried out by the platform or DevOps team that owns the playbooks, often with an implementation partner for the access model and cutover. Semaphore UI is licensed under the MIT license and comes in three editions: Community at no license cost, Pro with paid per-instance licensing, and Enterprise priced by quote.

Effort depends mostly on how many job templates, credentials and survey-driven workflows exist and how much of the access model must carry over. Before estimating, inventory every AAP organization, team, credential, workflow and schedule, then mark which ones are still used. Confirm which AAP features your playbooks depend on, such as certified collections from automation hub or Event-Driven Ansible rules, because Semaphore UI does not replace those one for one. Ask Semaphore UI's team, or test in your own environment, how it handles the Ansible content and secrets you use today. Those answers, not the object count alone, set the schedule and the risk.

Plan for a parallel run before any cutover. Keep AAP executing production jobs while Semaphore UI runs the same playbooks against a non-production inventory, and compare results, host facts and failure notifications. Map each AAP role to a Semaphore UI project role and confirm which controls you need. LDAP and Active Directory integration, OIDC single sign-on, project runners for isolated networks and role mapping from identity provider groups are Pro or Enterprise features according to the Semaphore UI pricing page, so decide early whether Community is enough. Document the decisions and ask any vendor or implementation partner to put the scope, deliverables and timeline in writing before work starts.

Which AAP capabilities map to Semaphore UI and which need rework

This table compares the main automation controller areas you will move from Ansible Automation Platform with what Semaphore UI offers in each edition. Read each row as a planning checkpoint: clean means a near direct equivalent, needs rework means you will rebuild the object or process by hand, and gap means you should plan a workaround or confirm support before cutover. The main takeaway is that the object model moves with effort, while identity, high availability and surveys need explicit decisions.

Capability	Semaphore UI (Community and Pro/Enterprise)	Migration status
Projects	Git-backed repositories can hold playbooks, Terraform, OpenTofu, Terragrunt and scripts in one interface	Needs rework: recreate each project and confirm branch and credential links
Inventories	Inventories are defined in Semaphore and are not imported from AAP automatically	Needs rework: export host and group data and rebuild each inventory
Credentials (key store)	Key store holds SSH keys, passwords and other secrets used by templates	Needs rework: re-enter secrets and confirm each one is rotated during cutover
Job templates	Task templates map to playbooks with their variables and inventory selection	Needs rework: rebuild templates, then compare variables and extra vars with AAP exports
Surveys	Survey-style prompts for runtime variables should be confirmed against the current Semaphore documentation	Gap to confirm: check whether each survey question has a direct equivalent
RBAC	Community covers basic access control, while Enterprise adds custom roles and role mapping from identity provider groups	Needs rework: redesign permissions and confirm role mapping in your edition
Schedules	Scheduled task runs are available in Semaphore, so timing and targets must be re-entered	Needs rework: recreate each schedule and verify it fires once in parallel runs
Notifications	Semaphore sends notifications about failed tasks, so confirm channels match your existing alerting	Needs rework: reconfigure destinations and test failure paths
LDAP and SSO	Pro adds OIDC providers and LDAP or Active Directory, while Enterprise adds role mapping from groups	Clean on Pro or Enterprise: plan the identity setup before cutover, not on Community
Project execution	Pro adds project runners for isolated infrastructure, and Enterprise adds Kubernetes execution	Needs rework: map AAP execution nodes to runners and confirm network reach
High availability	High availability is listed only in Enterprise, and the Community edition does not include it	Gap on Community: plan a single-instance recovery approach or choose Enterprise

What to export, recreate and reconnect

Moving from Ansible Automation Platform to Semaphore UI means reconnecting four groups of dependencies: source repositories, inventories and variables, credentials and key stores, and the notification and identity integrations around them. AAP and Semaphore UI objects do not share a common export format, so most objects are recreated by hand or by script and then verified against the original runs.

Source repositories in Git

Playbooks, roles and collections should already live in Git, so the first step is confirming that every AAP project points at a repository you control and that the branch or tag each template uses is named. In Semaphore UI, each repository is added as a project resource with its own access key, and the playbook path is set per task template. Check that roles and collections referenced through requirements.yml resolve from the Semaphore runner, especially if your runner has no outbound access to public Galaxy servers. Run one template from each project before retiring the AAP original.

Inventories and variables

Static inventories, dynamic inventory scripts and group and host variables do not transfer as a single file. Export them from the AAP API or the controller's inventory views, then rebuild each inventory in Semaphore UI and compare host counts and group membership. Dynamic inventories need their source credentials and plugin configuration recreated, and any variables set through survey prompts must be mapped to Semaphore's own environment or variable definitions. Treat the comparison as a checklist, not an assumption.

Credentials and key stores

AAP credentials for SSH, cloud accounts, vault passwords and source control must be re-entered in Semaphore UI's key store, because encrypted secrets cannot be exported in a form the other platform can read. Plan who holds each secret, rotate credentials where the old values were shared widely, and record the mapping from each AAP credential to its new key. Confirm how the Semaphore instance encrypts stored keys and where its database backups go, since those backups will hold the new secrets.

Notifications and identity integrations

Notification targets, such as chat webhooks and email, and login integrations, such as LDAP or SSO groups, need separate treatment. Semaphore UI's Community edition does not provide LDAP or OIDC login, and its Pro edition adds both, so confirm which identity features your AAP setup depends on before choosing an edition. Map AAP teams and organization roles to Semaphore projects and roles manually, and test a failed-task notification from each template class during parallel running.

How to rebuild projects, key stores and task templates in Semaphore UI

Start by moving every playbook, role and inventory file into Git, because Semaphore UI runs projects from repositories and every later object depends on that source. Confirm that each AAP project maps to one repository and branch, and that the playbook paths still resolve from the repository root. Then recreate the key store entries before any task template, so that SSH keys, become passwords and Ansible Vault passwords are entered once into Semaphore and never copied out of AAP as plain text. AAP stores its credentials encrypted, so the secret values should come from your original source, such as a password manager or vault, under a documented change record. Next, rebuild inventories and task templates, and run each template in check mode against a non-production host before you trust it.

Map access control after the objects exist, not before. AAP organizations, teams and object roles need to be translated into Semaphore project roles, and the mapping should be written down user by user for the groups that run production jobs. Pro adds LDAP and Active Directory and OIDC sign-in, while role mapping from identity provider groups and custom roles are listed only in Enterprise, so confirm which of these your team needs before you plan the identity setup. Surveys have no direct one-to-one equivalent. Each survey question must be redesigned as a template variable with a default, or as a prompt where the operator must enter a value at launch. Review each redesigned survey with the people who fill it in today, since their input is often the only record of which answers are valid.

Recreate schedules last and disable each AAP schedule before enabling its Semaphore counterpart, so that the same job never runs on both platforms. Check the time zone of every schedule explicitly, because AAP and Semaphore may interpret the same wall-clock time differently, and daylight saving changes can shift a run by an hour twice a year. List the schedules that fire within the same window and confirm that concurrent jobs do not touch the same hosts or locks. Keep a record of the first few scheduled runs in each platform during the parallel period, comparing start times, outcomes and logs. Confirm the scheduler behavior and any retention limits for run history in the Semaphore release you install, as the project documentation at the Semaphore UI repository is the authoritative reference.

The migration sequence from inventory to decommission

This sequence moves playbook automation from Ansible Automation Platform to Semaphore UI in controlled stages, so each object, job and team is verified before AAP is switched off. Each step produces a written artifact that the next step depends on.

Inventory every AAP object and job
Platform owners list every organization, project, inventory, credential, job template, workflow, schedule, survey and RBAC assignment in automation controller, and note which job templates are run by which teams and which external systems call them through the API. Include Event-Driven Ansible rulebooks and any private automation hub content they depend on. The output is an object register that maps each AAP object to its Semaphore equivalent or to a decision to retire it. The step is done when the register has an owner and a target for every row.
Pilot one low-risk project
Choose one playbook project that touches non-production hosts, has a small number of credentials and has a named owner willing to test it. Recreate its project, inventory, key store and task template in a Semaphore UI instance, using a Community install or a Pro trial if LDAP or project runners are needed. Run it, schedule it and confirm notifications reach the right people. The output is a pilot report that records what translated cleanly, what needed rework and which AAP features had no direct equivalent.
Build a parity checklist from the pilot
Use the pilot report to write a parity checklist covering inventory variables, vault or key handling, survey questions converted to task inputs, access rules mapped to Semaphore roles, and schedules with their time zones. Assign each item to a person who will verify it against the AAP original. The checklist should also list features that will not carry over, such as certified collection content or AAP-specific workflow approvals, with an agreed workaround for each. The step closes when every item is marked as matched, replaced or accepted as a gap.
Run both platforms in parallel
Point the migrated templates at non-production hosts and let AAP and Semaphore UI execute the same playbooks against them over an agreed period. Compare job results, changed-task counts, failure messages and timing, and record each difference with its cause. Keep AAP as the only path to production during this stage. The output is a parallel run log that shows whether results match and which gaps remain open. Parallel running ends when the owners sign off the log against the parity checklist.
Cut over by project or environment
Move production work one project or environment at a time, starting with the group that carries the least risk. For each move, update schedules, webhooks and any external callers to target Semaphore UI, and confirm access for every team that needs it. Write a cutover runbook that states the change steps, the rollback path back to AAP, and the person who can authorize a rollback. The step is complete when each project has run in production on Semaphore UI for a full cycle of its normal schedule without an open incident.
Archive AAP and decommission after retention
Once all projects are on Semaphore UI, export the AAP configuration, job history and audit records, and store them under the retention rules your compliance team sets. Confirm with your auditors which evidence they need, including credential and access records, before deleting anything. Then disable AAP schedules, revoke its tokens and credentials, and shut down the controller and hub. The output is an archive of the AAP configuration with a decommission record that lists what was removed, when, and who approved it.

What drives cost and duration in this migration

This table lists the inputs that move the cost and effort of an AAP to Semaphore UI move, and whether each one is paid once or every period. Use it to structure a written scope request, since the largest variables are object count, feature needs and how much testing you require. The main takeaway is that Semaphore's license line is small relative to the rebuild, testing and cutover work, so the quote should itemize those parts.

Cost driver	What changes the effort or cost	One-time or recurring	What to ask for in a quote
Projects, templates and inventories	Each AAP project, job template, inventory and host group must be recreated by hand or scripted through the Semaphore API. Higher counts mean more rebuild and review time.	One-time	Count of objects in scope, the method (manual or scripted) and a list of what will be migrated versus retired
Surveys and custom credential types	AAP surveys have no direct one-to-one equivalent in Semaphore, so each survey usually needs a redesigned variable prompt or wrapper. Custom credential types need separate mapping into Semaphore key stores.	One-time	A per-survey and per-credential-type inventory with the proposed replacement for each
RBAC, LDAP and SSO needs	Directory login (LDAP or Active Directory) and OIDC SSO are Semaphore UI Pro features, and role mapping from identity provider groups is listed for Enterprise. Your access model determines which edition you must buy.	Recurring (license) plus one-time (configuration)	Confirmed edition for each login method, group-to-role mapping and whether role mapping must be in scope
Project runners for isolated networks	Hosts in segmented or restricted networks need project runners, which the Pro edition includes. More segments mean more runners to deploy, secure and monitor.	One-time (setup) plus recurring (runner hosting)	Number of network zones, runner placement and the connectivity tests planned for each zone
Air-gapped licensing	Air-gapped operation is listed as an Enterprise feature, priced by quote. Networks without outbound internet access need this arrangement confirmed before design starts.	Recurring (license, by quote)	Written confirmation of licensing terms for offline deployment and the update process for air-gapped installs
Hosting, backup and recovery	Semaphore runs as a self-hosted service with its own database, so you pay for compute, storage, backups and restore testing. Costs rise with HA requirements, which the Community edition does not include.	Recurring (infrastructure) plus one-time (backup design and restore test)	Hosting footprint, backup schedule, restore test scope and whether high availability is required
Testing and parallel running	Each migrated template should be compared with its AAP run output. Running both platforms in parallel during cutover adds licence and infrastructure time until AAP is retired.	One-time (testing, cutover) plus recurring for the overlap period	Test plan, acceptance criteria, cutover window and the date AAP subscription ends
Staff time and support	Internal engineers handle rebuild, review and ongoing patching. Community support is informal, while Pro includes a business-hours support SLA, so the support model affects who carries incident work.	One-time (migration effort) plus recurring (operations and support)	Named responsibilities, expected staff hours by phase and the support tier chosen for production

What usually goes wrong and how to prevent it

Moving playbook runs from Ansible Automation Platform to Semaphore UI tends to fail in predictable places: credentials, schedules, access rules, alerts, failure handling and the single-instance limits of the Community edition. Each card below names one risk and a check to run before cutover, so the parallel run can prove the new setup before AAP is switched off.

Secrets copied in plaintext

Credentials from AAP's credential store are often re-entered into Semaphore's key store by copying them from old vault files, shell history or spreadsheets. Plaintext copies then sit in exported inventories, Git repositories and chat threads. Before cutover, confirm that every key store entry was created in Semaphore, that no secret appears in playbook variables or task arguments, and that the source copies are removed or rotated.

Unnoticed schedule drift

Schedules that ran nightly in AAP can be recreated with the wrong time zone, cron expression or target template, or left enabled on both platforms during the parallel run. The result is duplicate changes or jobs that quietly stop. Compare each schedule's expression, time zone, template and enabled state against the AAP export, and disable the AAP copy only after the Semaphore run history matches for a full cycle.

RBAC gaps that widen access

AAP's organization, team and role assignments do not map one to one onto Semaphore's project roles. A user granted a broad role in a convenience pass can run production templates they never used in AAP. Before go-live, list each AAP team and its permissions, map them to Semaphore roles per project, and confirm that a test user cannot see or run templates outside their scope. Community has no LDAP or OIDC, so accounts must be managed locally unless Pro is licensed.

Missing failure notifications

AAP notifications attached to job templates may not be recreated, so a failed production run goes unreported until someone checks the UI. Semaphore sends notifications about failed tasks, but the destinations, triggers and recipients must be configured again for each project. Test a deliberately failing task in every project and confirm the alert reaches an on-call channel that someone monitors.

Untested failure paths

Migrated templates are usually tested only on the success path, while AAP workflows that branched on failure, retried or ran cleanup steps may not have been rebuilt. A partial failure can then leave hosts half configured. For each critical template, write down the expected behavior on failure, run it against a non-production inventory, and confirm the rollback or cleanup step runs as before.

Community without HA for critical runs

The Community edition does not include high availability, which Semaphore lists only in Enterprise. If the single instance is down during a change window, scheduled and manual runs stop with it. Decide which templates are critical, confirm the recovery time your change process requires, and ask Semaphore whether Pro or Enterprise licensing fits that requirement before using Community for production runs.

How the move differs by starting point

A small team with a handful of projects usually has one or two administrators, a short list of inventories and few or no surveys. The migration is mostly a rebuild by hand, and the main risk is losing a schedule or credential that nobody wrote down. Because the object count is low, you can recreate everything in one pass and keep the old controller available only until the first full run succeeds.

Object count: List every project, inventory, key and task template before you start. A short list can be rebuilt in a single working session.
Schedules: Export the schedule list from the controller and confirm each one has a Semaphore UI equivalent before you disable the old job.
Access model: A few admins may not need custom roles. Confirm that the Community edition's roles cover your current users before deciding whether Pro is worth it.
Installation: A single Docker host is usually enough. Confirm the backup approach for the Semaphore database, since you own it.
Community support: Expect to rely on the project's public channels rather than a vendor support line.

Before cutover, confirm with your team that every scheduled run has a named owner and that a failed run sends a notification to someone who will act on it.

Questions buyers ask before moving from AAP to Semaphore UI

What does a migration from Ansible Automation Platform to Semaphore UI cost?

The cost has two parts: the software licence and the people time. Semaphore UI Community is free under the MIT license, and the pricing page lists Pro from $20 per month or $199 per year for the starting configuration, so the licence line is small and known. Your AAP subscription is the cost you stop paying, and it is quoted by Red Hat. The larger, one-time cost is labor: exporting and recreating projects, inventories, key stores and task templates, rebuilding RBAC and schedules, and testing. Hosting, backups and your own support time recur. Ask DeployOpen for a fixed-scope written quote that lists each object type, environments in scope and cutover support, and ask Red Hat to confirm your current subscription terms.

How long does it take to move playbook runs from AAP to Semaphore UI?

Duration depends on how many objects you have and how much of your RBAC and scheduling logic has to be redesigned. The supplied sources do not give a migration timeline, so treat any number as something to confirm in a written scope. The work usually follows a sequence: inventory the AAP estate, stand up Semaphore in a test environment, recreate projects and inventories, convert surveys into Semaphore task variables where needed, validate runs against non-production hosts, then schedule cutover. Ask for the expected duration per phase and the acceptance tests that close each phase.

What does the internal team need to provide during the migration?

Your team needs to provide knowledge of the automation itself, not just access. Expect to supply the list of job templates, the inventories and their sources, the credentials and which systems they unlock, the RBAC model that decides who runs what, and the schedules that run in production. Security and identity staff should confirm how users authenticate, because Community does not include LDAP or OIDC, and Pro adds SSO and LDAP. A named owner who can approve each cutover step and access to target systems for testing are the items most often underestimated.

Can our own engineers migrate to Semaphore UI without outside help?

Yes, a capable team can do it internally, provided it has time, a test environment and someone who has run AAP in production. Semaphore's README describes Docker as the recommended install method, and the project publishes its installation options, so the platform itself is not difficult to stand up. The risk is in the details that AAP handled quietly: credential handling, RBAC translation and scheduled runs that nobody documented. If your team lacks that capacity, a fixed-scope engagement from DeployOpen can cover planning, implementation, hardening, documentation and cutover support. Confirm with Semaphore UI which edition your required features need before you start.

Is Semaphore UI Community enough, or do we need Pro or Enterprise?

Community is enough when you run playbooks, Terraform or OpenTofu code and scripts for a small group of users and authenticate locally or through an approach you can manage yourself. Pro adds SSO through OIDC providers such as Okta, Entra ID, Keycloak and Google, plus LDAP and Active Directory, project runners for isolated infrastructure and a business-hours support SLA. A single Pro license caps at 500 nodes, 5,000 resources, 25 users, 25 runners and 3 instances. Enterprise, priced by quote, adds high availability, Kubernetes execution, role mapping from identity provider groups, custom roles and air-gapped licensing. The pricing page notes that Community has no high availability. Map each AAP feature you use to an edition before choosing.

How do we run AAP and Semaphore UI side by side during cutover?

Run both platforms against the same target hosts, but assign each playbook to one owner at a time so no host is changed twice. Start by moving low-risk, read-only or check-mode jobs, then move scheduled jobs one by one, disabling the AAP schedule only after the Semaphore version has passed its checks. Keep AAP read-only for a defined rollback window, and keep its credentials and database backed up. Record which system owns each job in a shared register. Ask your DeployOpen scope to name the rollback criteria and the person who can invoke them.

What happens to our AAP credentials and secrets during the move?

Credentials must be re-entered or re-created in Semaphore's key store, not copied from AAP, because AAP does not export its encrypted secret values in a form you can simply import. Plan to rotate sensitive credentials during the move where your policy requires it, and restrict who can view them in Semaphore. Confirm with Semaphore UI how its key store is encrypted and backed up in your chosen install method, and record the owner and access list for each credential. If you use an external secrets manager, decide whether Semaphore will fetch secrets from it or hold copies.

Official Semaphore UI sources to check during planning

Before you scope a move from Ansible Automation Platform to Semaphore UI, check the current feature list, version and edition boundaries against Semaphore's own sources. The GitHub repository is the place to confirm what the MIT licensed Community edition runs today, including Ansible playbooks, Terraform and OpenTofu code, Terragrunt, Bash and PowerShell scripts, and how it handles notifications and access control. Read the README for the supported install methods, since Docker is the recommended path and the other options (VM images, Snap, a binary, or Debian and RPM packages) change the way you will back up and upgrade the instance.

The releases page tells you which version you would actually deploy. The most recent release named in the supplied facts is v2.19.16, published on October 7, 2026, but new versions appear regularly, so confirm the latest tag on the day you plan. Read the release notes for changes to projects, task templates, key stores, runners and the database schema, because those are the areas your migration will touch. Pin the version you test against and record it in your cutover plan so that the parallel run and the production instance match.

The pricing page is where you confirm which controls sit behind the paid editions before you assume they exist in your environment. Check the current Pro entry price and terms, and confirm which features are included: OIDC single sign-on, LDAP and Active Directory, project runners, the business-hours support SLA and the license limits on nodes, resources, users, runners and instances. Check Enterprise separately for high availability, Kubernetes execution, role mapping from identity provider groups, custom roles and air-gapped licensing. Ask Semaphore in writing to confirm any feature your RBAC or surveys replacement depends on, because the Community edition does not include high availability.

How DeployOpen works on this

DeployOpen plans and implements the move from Ansible Automation Platform to Semaphore UI inside your own infrastructure, starting with an inventory of the projects, inventories, credentials and schedules you actually run. Engagements are fixed-scope, so the mapping, deliverables and timeline are agreed in writing before any work starts.

How we scope

Inventory every AAP job template, workflow, survey, schedule and credential to decide what is recreated, simplified or retired.
Record which Pro or Enterprise features you need, such as LDAP, OIDC, project runners or high availability, before choosing an edition.
Agree in writing the hosting target, cutover window, parallel-run period and the acceptance tests that close the engagement.

How we build

Deploy Semaphore UI with Docker or another supported install method in your environment, with secrets kept in your own key store.
Recreate projects, inventories, key stores and task templates as code where possible so the configuration can be reviewed and versioned.
Map AAP roles and surveys to Semaphore access controls and task inputs, and test each playbook run against staging hosts before cutover.

How we hand over

Document the target architecture, object mapping, access model and every gap against automation controller that remains open.
Provide a runbook for the parallel-run period, the rollback path to AAP and the criteria for switching off the old platform.
Walk your platform and operations teams through day-to-day task runs, schedule changes, backups and upgrade steps.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover, scoped separately in writing.
Confirm with Semaphore UI which edition, support level and license limits fit your node, user and runner counts before go-live.
Agree with your compliance and audit teams which evidence DeployOpen will prepare and which independent auditors must assess.

Migrate from Ansible Automation Platform to Semaphore UI