O Jira Cloud Migration Assistant é a ferramenta oficial e gratuita da Atlassian para mover dados de Server ou Data Center para o Cloud, descrita pela própria documentação como o método mais fácil e confiável. Seu princípio de operação é importante e costuma ser mal entendido: ele adiciona dados ao site de Cloud sem sobrescrever o que já existe, o que permite migrar para um site novo ou para um site com dados. O ponto que derruba projetos não está no que ele leva, e sim no que ele não leva e no único caso em que ele sobrescreve. Alguns campos não são migrados e precisam ser recriados e preenchidos manualmente depois, por importação de CSV, e existe um cenário específico de sobrescrita ao migrar tipos de item gerenciados que foram renomeados. Quem trata migração como copiar tudo de um lado para o outro descobre a diferença quando o histórico chega incompleto e o indicador do outro lado não bate.

Por que essa migração deixou de ser opcional e ganhou pressa

O encerramento do suporte ao Jira Server tirou a decisão da mesa de muitas empresas: continuar no Server deixou de ser uma opção com suporte, e a migração para Cloud, ou para Data Center como passo intermediário, passou a ser questão de quando, não de se. O efeito colateral dessa pressa é previsível. Migração conduzida com prazo apertado tende a ser avaliada por um único critério, o de que os projetos apareceram do outro lado e as pessoas conseguem trabalhar.

Esse critério esconde o problema mais caro, porque ele não aparece no dia da virada. Aparece semanas depois, quando alguém tenta rodar um relatório histórico e descobre que uma parte do passado não veio, ou veio em um formato que as regras existentes não reconhecem. A operação segue funcionando; a memória da operação é que ficou com buracos.

A tese deste guia: migração de Jira bem-sucedida não é a que faz as pessoas trabalharem no dia seguinte, é a que preserva a capacidade de perguntar ao passado. As duas coisas são diferentes, falham em momentos diferentes e são avaliadas por pessoas diferentes. Quem valida a migração pela operação dá o projeto por encerrado antes de descobrir o que aconteceu com o histórico, e histórico perdido raramente se recupera depois que o Server foi desligado.

O que o assistente leva, e o que ele deixa para trás

O comportamento padrão é aditivo: a documentação afirma que o assistente adiciona dados ao Cloud sem sobrescrever nenhum dado existente. É por isso que a Atlassian oferece um relatório de pré-migração, que mostra o que está incluído no plano antes de rodar, e é nele que se deve olhar primeiro. A parte que exige trabalho manual é a dos campos que não são migrados: a orientação oficial é criar os campos que não vieram, associá-los às telas relevantes usando os logs do Server, onde se procura pela marcação de campo customizado não suportado, e completar os valores por importação de CSV depois da migração.

A documentação da Atlassian registra explicitamente o caso de exceção: embora o assistente normalmente adicione dados sem sobrescrever, há um cenário em que a sobrescrita pode ocorrer, ao migrar tipos de item gerenciados renomeados como o Epic. Reproduzir isso sem exagero importa, porque é o único ponto em que o modelo aditivo não se aplica, e é justamente onde um projeto desavisado perde dado.

Os três riscos de dado que a pressa esconde

1 · O campo que virou coluna vazia

O campo que não migra e é recriado depois volta a existir com o mesmo nome e sem o histórico. Para quem trabalha no presente, está tudo lá. Para qualquer análise que dependa daquele campo ao longo do tempo, existe um buraco entre a data da criação no Server e a data do preenchimento no Cloud. Se esse campo alimenta um indicador, o indicador mostra uma série que parece começar do zero num ponto arbitrário, e a leitura executiva interpreta como mudança de comportamento o que é apenas artefato de migração.

2 · O identificador que mudou de valor

Este é o risco que amarra a migração ao pipeline analítico, e o que quase ninguém antecipa. Migração não preserva necessariamente os identificadores internos que o Server usava. Qualquer pipeline, painel ou integração que referenciava aquele dado por identificador interno, em vez de por uma chave estável, passa a apontar para o vazio ou para o registro errado depois da virada. É a mesma fragilidade que já tratamos ao falar de regras amarradas ao nome de um status, agora multiplicada pela quantidade de referências que uma migração desloca de uma vez. A verificação precede a migração: mapear o que consome o dado do Jira antes de mover, não depois de o painel cair.

3 · A configuração que chegou diferente

O assistente rastreia entidades para evitar duplicatas, guardando um registro de cada entidade migrada e comparando em migrações seguintes se ela é idêntica. Isso é uma proteção, e também um ponto de atenção: quando a configuração da origem e do destino não batem exatamente, o comportamento pode não ser o esperado, e a própria documentação recomenda verificar filtros JQL e filtros rápidos que dependam dessas entidades após migrar. Configuração que chegou levemente diferente é o tipo de discrepância que não impede o trabalho e distorce silenciosamente qualquer relatório que dependa da precisão dela.

A verificação que separa migração de TI de migração com dado (consultoria Databricks)

A diferença entre uma migração que preserva a memória e uma que a fragmenta está em uma pergunta feita antes da virada: quem consome o dado do Jira fora do Jira, e por qual referência? Enquanto o dado é lido apenas dentro da própria ferramenta, a migração é assunto de administração. No momento em que existe um pipeline analítico do outro lado, a migração vira também um evento de dados, e precisa ser planejada como tal.

Do lado da plataforma de dados, os mecanismos que respondem a essa pergunta já existem. A linhagem no Unity Catalog é capturada automaticamente em tempo de execução, com granularidade até o nível de coluna, e a linhagem externa permite registrar as ferramentas de consumo que operam fora da plataforma. Isso transforma a pergunta sobre o que quebra com a migração de suposição em consulta. E, do lado da ingestão, preservar a camada bruta do dado permite reprocessar o histórico quando a referência muda, em vez de aceitar a série partida como definitiva. Migração planejada com essa visão trata a virada como uma mudança de contrato de origem anunciada, e não como uma surpresa que o pipeline descobre sozinho.

Por que a migração exige as duas competências ao mesmo tempo: quem domina só o lado Atlassian conduz o assistente com perfeição e não enxerga que uma referência deslocada quebrou um painel a jusante. Quem domina só o lado de dados vê o painel quebrar e não tem acesso à origem que mudou. A migração que preserva a memória precisa das duas leituras antes da virada. A CSP Tech opera as duas pontas, como Atlassian Gold Partner na condução da migração e especialistas Databricks na fronteira com o consumo analítico, o que permite planejar a virada como um evento único, e não como dois projetos que se encontram no incidente.

A sequência que preserva o histórico

•     Antes: leia o relatório de pré-migração como inventário. Ele mostra o que está de fato no plano. O que não está ali é o trabalho manual que você terá, e é melhor saber o tamanho dele antes de marcar a data.

•     Antes: mapeie quem consome o dado fora do Jira. Pipelines, painéis e integrações que referenciam o dado por identificador interno são os que quebram na virada. Este mapeamento precede a migração, não a sucede.

•     Antes: identifique tipos de item gerenciados renomeados. É o único cenário de sobrescrita documentado. Tratá-lo antes evita a única forma de perda direta de dado da migração.

•     Depois: complete os campos não migrados por CSV, conforme a orientação oficial. E registre a lacuna temporal de cada um, para que a análise histórica saiba onde a série tem um corte de migração e não um evento de negócio.

•     Depois: teste filtros, JQL e os consumidores externos. A própria Atlassian recomenda verificar filtros que dependem das entidades migradas. Estenda esse teste aos painéis e pipelines do outro lado da fronteira.

Quando o cuidado completo é desproporcional

•     Instância pequena, sem histórico relevante e sem consumo externo. Se o valor está no trabalho corrente e ninguém consulta o passado nem lê o dado fora do Jira, a migração assistida direta resolve, e o esforço de preservação de histórico não se paga.

•     Quando o histórico já será deliberadamente descartado. Algumas migrações são a oportunidade de recomeçar limpo. Se essa é a decisão consciente, com aval de quem depende do histórico, não há memória a preservar.

•     Migração de escopo reduzido e projeto isolado. Mover um único projeto sem consumidores externos é um evento contido, e a verificação de fronteira analítica pode ser proporcionalmente menor.

Perguntas frequentes

O Jira Cloud Migration Assistant migra tudo?

Não. A ferramenta adiciona dados ao Cloud sem sobrescrever o existente, mas alguns campos não são migrados e precisam ser recriados e preenchidos manualmente depois, por importação de CSV, conforme a orientação da Atlassian. O relatório de pré-migração mostra o que está incluído no plano antes de rodar, e é onde se deve verificar o escopo real. Há ainda um cenário específico de sobrescrita ao migrar tipos de item gerenciados renomeados, que é a exceção ao comportamento aditivo.

O que pode dar errado com o histórico numa migração de Jira?

Três coisas que não aparecem no dia da virada. Campos não migrados e recriados depois voltam sem histórico, criando um corte temporal na série. Identificadores internos que mudam quebram pipelines e painéis que referenciavam o dado por essa via. E configurações que chegam levemente diferentes distorcem relatórios sem impedir o trabalho. As três se manifestam semanas depois, quando alguém consulta o passado, e não no momento em que a operação volta a funcionar.

Migração de Jira afeta os relatórios e o BI que dependem dele?

Pode afetar, e é a parte mais subestimada. Qualquer pipeline, painel ou integração que consome o dado do Jira por identificador interno ou por nome de entidade pode apontar para o vazio ou para o registro errado após a migração. A verificação precede a virada: mapear quem consome o dado fora do Jira antes de mover. Do lado da plataforma de dados, a linhagem permite responder o que quebra com a mudança, e preservar a camada bruta permite reprocessar o histórico quando a referência muda.

Como planejar uma migração de Jira Server para Cloud sem perder dado?

Tratando a virada como evento de dados, e não só de TI. Antes: ler o relatório de pré-migração como inventário, mapear os consumidores externos do dado e identificar tipos de item gerenciados renomeados, que é o único cenário de sobrescrita. Depois: completar os campos não migrados por CSV registrando a lacuna temporal de cada um, e testar filtros, JQL e os painéis e pipelines do outro lado da fronteira, estendendo a verificação que a Atlassian já recomenda para filtros.

Próximo passo

Se a sua empresa vai migrar o Jira, ou já migrou e desconfia que o histórico chegou incompleto, o teste que antecede qualquer plano é uma pergunta: quem consome o dado do Jira fora dele, e por qual referência? A resposta define se a sua migração é um evento de TI ou um evento de dados. Solicite uma avaliação de migração Jira Cloud com a CSP Tech e receba o mapa do seu caso: o que o assistente não vai levar, quais consumidores externos estão em risco na virada e o que precisa ser preservado para o histórico continuar respondível.

Autor: Guilherme Matos, estrategista de conteúdo e IA, certificado HubSpot, Google, Anthropic e Semrush. Revisão técnica por especialistas Atlassian e de dados da CSP Tech (Atlassian Gold Partner, parceira Databricks, Microsoft Gold Partner, participante do Anthropic Partner Network, 34 anos de mercado, produto próprio Power BI for Jira no Atlassian Marketplace).



Fontes (oficiais, acesso set/2026): Atlassian Support, “What gets migrated with the Jira Cloud Migration Assistant”, quanto ao comportamento aditivo sem sobrescrever dados existentes, ao relatório de pré-migração, aos campos que não são migrados e ao procedimento de recriação e preenchimento por importação de CSV usando os logs do Server (support.atlassian.com/migration). Atlassian Support, “How the Jira Cloud Migration Assistant links your data”, quanto ao registro de entidades para evitar duplicatas, ao cenário específico de sobrescrita ao migrar tipos de item gerenciados renomeados como Epic, e à recomendação de verificar filtros JQL e filtros rápidos que dependam dessas entidades após migrar (support.atlassian.com/migration). Atlassian Support, “Cloud migration methods for Jira”, quanto à descrição do assistente como método recomendado e à existência do CSV import como alternativa com limitações (support.atlassian.com/migration). Databricks Documentation, quanto à linhagem no Unity Catalog capturada automaticamente com granularidade de coluna, à linhagem externa para ferramentas de consumo, e à camada bruta da arquitetura medalhão como base para reprocessamento (docs.databricks.com). A distinção entre migração de TI e migração de dados e a organização em três riscos são formulação editorial da CSP Tech. Nenhum número fora das fontes citadas foi utilizado, e nenhuma data de fim de suporte específica foi afirmada sem verificação, sendo tratada apenas como fato de mercado já ocorrido.