Jira Cloud Migration Governance

Why Jira Migrations Fail

Most Jira Cloud migrations don't fail because of technical issues. They fail because of governance gaps: unclear ownership, no cleanup before migration, poor stakeholder communication, and no cutover plan.

This playbook gives you the governance framework to avoid those failures.

Phase 1: Assessment & Readiness (Weeks 1-4)

Inventory Audit

Before you migrate anything, understand what you have:

• Projects: How many? Which are active vs abandoned?
• Workflows: How many custom workflows? How many are duplicates?
• Custom fields: How many? Which are actually used?
• Schemes: Permission schemes, notification schemes, issue type schemes
• Apps / Plugins: Which are Cloud-compatible? Which need alternatives?
• Integrations: What connects to Jira? CI/CD, Confluence, Slack, etc.
• Users: Active users, inactive users, service accounts
• Data volume: Issues, attachments, comments, history

Readiness Scorecard

Score each area 1-5:

| Area | Score | Notes | |------|-------|-------| | Data cleanliness | | | | App compatibility | | | | User readiness | | | | Integration mapping | | | | Stakeholder buy-in | | | | Rollback plan | | |

If any area scores below 3, it's not ready to migrate.

Stakeholder Mapping

Identify and engage:

• Executive sponsor — owns the business case
• Jira admins — own the technical migration
• Team leads — own team readiness and communication
• Power users — early adopters who can champion the change
• Reluctant users — need extra support and communication

Phase 2: Cleanup (Weeks 5-8)

Do NOT migrate mess. Clean up before you move.

Project Cleanup

• Archive projects with no activity in 12+ months
• Merge duplicate projects
• Standardise project naming conventions
• Remove test/sandbox projects

Workflow Cleanup

• Identify workflows that do the same thing with different names
• Consolidate to a standard set (ideally 3-5 workflows max)
• Document each workflow's purpose and which projects use it

Field Cleanup

• Delete custom fields with <5% usage
• Rename fields to follow a naming convention
• Remove duplicate fields (e.g., "Due Date" vs "Target Date" vs "Deadline")
• Document which fields are required vs optional

User Cleanup

• Deactivate users who haven't logged in for 6+ months
• Review and update group memberships
• Document service accounts and their purposes

Phase 3: Migration Planning (Weeks 9-12)

Migration Strategy

Choose your approach:

• Big bang: Everything migrates at once. Faster but higher risk.
• Phased: Migrate project by project or team by team. Slower but lower risk.
• Hybrid: Migrate low-risk projects first, then critical ones.

For enterprise environments, phased is almost always the right choice.

Communication Plan

| When | Who | What | Channel | |------|-----|------|---------| | 8 weeks before | All users | Migration announced, timeline shared | Email + Confluence | | 4 weeks before | Team leads | Detailed plan, what changes for their team | Meeting | | 2 weeks before | All users | Training materials, FAQ, support channels | Email + Slack | | 1 week before | All users | Final reminder, freeze period announced | Email | | Migration day | All users | Status updates every 2 hours | Slack channel | | Day after | All users | Confirmation, known issues, support | Email + Slack |

Training Plan

Don't assume people will figure it out. Provide:

• 15-minute video walkthrough of key differences
• Written FAQ document
• Drop-in support sessions for the first 2 weeks
• Dedicated Slack channel for questions

Phase 4: Cutover (Week 13)

Pre-Cutover Checklist

• All cleanup tasks complete
• All apps tested in Cloud sandbox
• All integrations tested
• Rollback plan documented and tested
• Communication sent to all users
• Support team briefed and ready
• Freeze period communicated (no changes to Server during migration)

Cutover Day

• Start early (low-traffic hours)
• Run migration tool
• Validate data: spot-check 20 projects across different types
• Test critical workflows end-to-end
• Test integrations
• Confirm user access
• Send "migration complete" communication

Post-Cutover (Weeks 14-16)

• Monitor support channel closely for 2 weeks
• Track and resolve issues daily
• Collect feedback from team leads
• Document lessons learned
• Decommission Server instance (after 4-week parallel run)

Governance Cadence

During migration:

• Daily: Migration team standup (15 min)
• Weekly: Stakeholder update (status, risks, decisions needed)
• Fortnightly: Steering committee (escalations, budget, timeline)

Common Pitfalls

1. Migrating without cleaning up first — you'll just have the same mess in Cloud 2. Underestimating app compatibility — some Server apps don't exist in Cloud 3. No rollback plan — always have one, even if you never use it 4. Insufficient training — "it's just Jira" is not a training plan 5. Ignoring change resistance — some users will resist. Plan for it.

---

Download the [Jira Governance Checklist template](/templates) for a 40-point audit you can run before and after migration.