Gaps Críticos
Estes representam diferenças significativas de funcionalidade que requerem decisões arquiteturais antes da migração.
Gap 1: Hierarquia de Work Items (4 níveis → 3 níveis)
| Severidade | Crítico |
| Problema | ADO suporta Epic → Feature → User Story → Task (4 níveis). Jira Standard suporta apenas Epic → Story → Sub-task (3 níveis). O nível Feature não tem equivalente. |
| Impacto | Planejamento a nível de portfólio que depende de Features é interrompido. Times perdem uma camada de categorização. |
| Workaround | Opção A (Jira Premium): Usar hierarquia custom — Initiative → Epic → Story → Sub-task. Mapear Feature → Epic. Opção B: Achatar Feature em Epic (perder granularidade). Opção C: Issue type custom "Feature" sem suporte nativo de hierarquia. |
| Recomendação | Jira Premium é fortemente recomendado para times que usam o nível Feature. |
Gap 2: Area Paths (Hierárquico → Plano)
| Severidade | Crítico |
| Problema | Area paths no ADO fornecem categorização hierárquica multi-nível (Backend\API\Auth). Jira não tem equivalente hierárquico. Components e Labels são planos. |
| Impacto | Escopo de team, rollups de relatórios e categorização de trabalho baseada em hierarquia de area são perdidos. |
| Workaround | Achatar em Components (Backend, Backend-API, Backend-Auth), usar cascading select custom fields, ou adotar uma convenção de labels (area:backend, area:api). |
| Recomendação | Definir uma estrutura clara de components pré-migração. Documentar o mapeamento de achatamento. Aceitar alguma perda de semântica hierárquica. |
Gap 3: Hierarquia de Iteration Paths (Aninhado → Plano)
| Severidade | Crítico |
| Problema | Iteration paths no ADO suportam hierarquias aninhadas (Release 1\Phase 1\Sprint 1). Sprints no Jira são planos (sem pai/filho). |
| Impacto | Planejamento a nível de release que agrupa sprints sob releases perde sua estrutura. |
| Workaround | Usar Fix Versions para agrupamento a nível de release. Sprints permanecem planos. Advanced Roadmaps (Premium) fornece tracking de releases baseado em timeline. |
| Recomendação | Mapear iterations de nível superior para Fix Versions e iterations folha para Sprints. |
Gap 4: CI/CD Nativo (Built-in → Externo)
| Severidade | Crítico |
| Problema | Azure Pipelines é totalmente integrado ao ADO (YAML pipelines, release gates, environments, approvals). Jira não tem CI/CD nativo. |
| Impacto | Rastreabilidade pipeline-to-work-item, build status em boards, tracking de deployment — tudo requer integração com ferramenta externa. |
| Workaround | Adotar Bitbucket Pipelines (Atlassian-native), GitHub Actions ou Jenkins. Usar os painéis "Deployments" e "Development" do Jira com integrações. |
| Recomendação | Decidir a ferramenta de CI/CD antes da migração. Configurar integrações de development tools no Jira (GitHub for Jira, Bitbucket, Jenkins plugin). |
Gap 5: Test Management (Nativo → Plugin Pago)
| Severidade | Crítico |
| Problema | Azure Test Plans é um serviço nativo e incluído (test cases, test suites, test runs, exploratory testing). Jira requer plugins pagos (Xray ~$10/user/mês, Zephyr Scale ~$8/user/mês). |
| Impacto | Custo adicional de licenciamento. Migração de dados de teste requer ferramentas especializadas. Rastreabilidade test-to-requirement deve ser reconfigurada. |
| Workaround | Comprar Xray for Jira (recomendado — mais feature-complete) ou Zephyr Scale. Ambos oferecem ferramentas de migração do ADO Test Plans. |
| Recomendação | Orçar o licenciamento do plugin de test management. Planejar uma fase separada de migração de dados de teste. |