Run platform migrations across dozens of Jira teams.
Launch migration work, track adoption, surface blockers, and keep every team moving from one place.
Jira tracks the tickets. Armada tracks the rollout.
- PaymentsPAY-502Done
- SearchSRCH-97Blocked
- IdentityID-260In progress
- CheckoutCHK-91Done
- NotificationsNTF-33Done
- BillingBIL-318Done
67% complete4 of 6 teams done
Search needs attention. Waiting on a network policy exception, no update in 9 days.
The new platform is ready. The last 20% of services are not.
Migrations stall in the long tail. Most teams move when the golden path is ready; the rest drift past the deprecation date while you keep both platforms running.
Adoption is a guess
You know how many services exist. You do not know, today, how many have actually cut over.
The tracker lives beside Jira
A migration spreadsheet maps services to owners and status. It is out of date the day after you update it.
Blockers surface late
A team needs a feature the platform does not support yet. You learn that in week six, not week one.
Laggards need chasing
The teams that have not started are the ones least likely to read the migration announcement.
Two platforms cost money
Every service still on the old stack delays decommissioning it, and you keep paying to run both.
Know which services have moved, and which have not.
One migration issue per team
Each owning team gets its migration issue in its own Jira project, linked back to one parent so nothing is lost.
Adoption as a number
Completion rolls up across teams, so "how far along are we?" has a current answer.
Blockers reach you early
Comments that mention a blocker are flagged in the roll-up, so you can fix the platform gap while there is still time.
The long tail gets reminders
Auto-nudge comments on migration issues that have gone idle, every day, until they move.
From migration plan to decommission.
List the service teams
Import teams and their Jira projects from CSV, or add them by hand. Reuse the list for the next migration.
Write the migration guide once
Put the runbook, the cutover checklist and the deprecation date in one parent Jira issue.
Launch to every service team
Each team gets its migration issue in one action. Armada reports any team it could not reach, with the reason.
Chase the long tail
Follow up with idle and blocked teams until every service has moved and the old platform can go.
What you will see in Armada
Armada runs inside Jira Cloud. Every team's work stays a normal Jira issue in its own project and workflow. These are the names Armada uses for the parts above.
- Campaign
- The migration, tracked from its parent Jira issue.
- Fleet
- Your service teams and their Jira projects.
- Mission Control and SITREP
- Migration progress across all teams, with blocked and stale teams called out.
- Auto-nudge
- Daily reminder comments on migration issues that have gone idle.
- Drift detection
- Warns when a team project is deleted, permissions change, or an issue type disappears mid-migration.
Before you install
Can teams keep their own Jira projects and workflows?
Yes. Each team gets a normal Jira issue in its own project. Armada reads status from those issues; it does not replace the team workflow.
What if a team joins the migration later?
Link its Jira issue to the parent. When Armada syncs the campaign it picks up linked issues, so late joiners count toward progress.
Does Armada connect to Kubernetes or our CI?
No. Armada tracks the Jira work for the migration. Teams close their issue when their service has moved.
Does it work with Compass?
Yes. If you use Atlassian Compass, Armada can show campaign progress on component pages.
Track your next migration in Jira, not in a spreadsheet.
Install Armada, import your service teams, and launch the migration from its parent issue.
Free 30-day trial through the Atlassian Marketplace. Jira Cloud only.