Choose an Atlassian partner for a Jira Cloud migration by what they will find before the move, not by how fast they say they can move you. Verify their tier and specializations in Atlassian's partner directory, then ask how they handle identity, apps, cutover, and the site after go-live.
Most partner shortlists are built from rankings. Rankings are a fine place to start, but they cannot tell you whether a partner will catch the problem that stalls your migration. That problem is rarely the data. It is the accounts nobody owns, the Marketplace app with no Cloud equivalent, or the automation rule that three teams depend on and nobody documented.
We are an Atlassian Platinum Solution Partner, so we have a stake in this question. This guide sticks to criteria you can check with any partner, including us.
Start with the partner directory
Atlassian lists its Solution Partners at partnerdirectory.atlassian.com. You can filter by country, solution, industry, company size, and type of service, and sort the results by tier. Each profile shows the partner's tier, its specializations, its sales and delivery accreditation counts, and its awards.
Two things to look at:
- Tier. Atlassian's levels are Silver, Gold, and Platinum, with Platinum the highest.
- Specializations. Atlassian's specializations are Cloud Migration, Service Management, Software Development, Enterprise Strategy & Planning, and Teamwork Foundations. For a migration, Cloud Migration is the one that matters most.
Tier and specialization tell you a partner is qualified. They do not tell you whether that partner is right for your estate. The questions below do.
Eight questions to ask every partner
1. What do you assess before you quote?
A fixed price with no discovery is a guess. A good partner wants exports first: users and groups, apps, custom fields, workflows, automation rules, and data volumes. Ask what the assessment produces and whether you keep it if you choose someone else.
2. How do you handle identity?
This is the question most shortlists skip. Ask how the partner reconciles users before the move, handles duplicates, and sets up single sign-on and SCIM provisioning in Cloud. SAML single sign-on and SCIM need Atlassian Guard, which Enterprise plans already include, so the plan should account for it. If identity is not a named workstream, it will surface after cutover as a licensing and access problem.
3. What is the plan for Marketplace apps and automation?
Some apps have Cloud versions with different features. Some have no Cloud version at all. Ask for an app-by-app plan: keep, replace, rebuild, or retire. Ask the same about automation rules and scripts, which rarely migrate as they are.
4. Phased or single cutover, and why for us?
There is no universal answer. Phased moves spread the risk but create a period where teams work across two platforms. A single cutover is shorter but needs more rehearsal. A partner should explain their recommendation using your integrations and team structure. We wrote about why a phased Jira migration can be the riskier choice.
5. How do you validate the data?
Ask what gets checked after each test migration: counts, history, attachments, links, and permissions. Ask who signs off and what happens when a check fails.
6. Who will actually do the work?
Ask for the names and roles of the people on your project, not just the firm's credentials. Ask who the architect is and how much of their time you get.
7. What happens after cutover?
Migration is the start of running the site in Cloud. Ask about hypercare, who fixes what breaks in week two, and how governance is handed to your team. A site with no rules after go-live drifts back to the state you migrated away from.
8. How do you handle licensing?
Partners can manage your Atlassian subscriptions. In a partner-managed subscription, you buy and renew through the partner instead of paying Atlassian directly. People your partner assigns as customer contacts can still see details such as the site, entitlement number, and user counts. Atlassian's pages say official partners can access special pricing, but they do not promise that a partner passes discounts on. Ask each partner what they offer and get it in writing.
Red flags
- A quote before anyone has looked at your estate.
- "We migrate everything as is" with no plan for apps, automation, or cleanup.
- No identity workstream, or single sign-on treated as a checkbox.
- No named architect.
- No plan for the weeks after cutover.
A scorecard for your shortlist
| Criterion | What good looks like | Partner A | Partner B | Partner C |
|---|
| Tier and Cloud Migration specialization | Verified in the partner directory | | | |
| Assessment before quote | Written findings you keep | | | |
| Identity workstream | User reconciliation, SSO, SCIM, duplicates | | | |
| App and automation plan | App-by-app decision with owners | | | |
| Cutover approach | Explained for your estate, with rehearsals | | | |
| Data validation | Defined checks and sign-off | | | |
| Named team | Architect and leads named in the proposal | | | |
| After cutover | Hypercare and governance handover | | | |
If you run more than one site, or more than one tool
Two situations change the shortlist. If you have several Jira sites, you need a partner that has merged sites before. Atlassian's cloud-to-cloud transfer copies most project data, but not automation rules, app data, or global permissions. Fields and schemes that don't match arrive as duplicates, and links in content point to the old site until you run Atlassian's link fixing. See our Jira site consolidation service for what that work involves.
If you are also moving off another tool, such as ServiceNow, the partner needs service management design skills as well as migration skills. There is no first-party tool that moves ServiceNow to Jira Service Management in one step, so the plan matters more than the tooling. Our ServiceNow to JSM migration page covers how we approach it.
Where Atlas Bench fits
Atlas Bench is an Atlassian Platinum Solution Partner. Our migration work puts identity and governance inside the scope, because that is where we see projects stall. We are a good fit when the estate is complex: several sites, identity that needs rework, apps and scripts that need a plan, or compliance requirements that need evidence. If you need a straight data move for a small, clean site, a smaller partner may be the more economical choice, and the questions above will still help you pick one.
Planning a Jira Cloud migration?
Talk to an Atlas Bench architect before you pick a partner. We'll walk through your estate, the identity and app questions above, and what a realistic plan looks like.
Talk to an architect See how we run migrations
Questions we get
Does partner tier matter?
It matters as a first filter, and the directory lets you check it in a minute. It does not replace asking how the partner will handle your specific estate.
Should we buy licenses through the migration partner?
You can. In a partner-managed subscription, you buy and renew through the partner. Compare what each partner offers, and ask Atlassian directly if you want a baseline.
How many partners should we talk to?
Three is usually enough. Give each the same exports and questions so you can compare answers side by side.
What is the most common reason migrations run late?
Surprises found after the plan is set: apps with no Cloud version, undocumented automation, and user and group problems. A proper assessment moves those surprises to the start.
Can we run the migration ourselves?
Yes, and Atlassian provides tools and guides for it, including the Jira Cloud Migration Assistant. Teams bring in a partner when the estate is large or complex, or when they cannot afford a failed cutover.
