1 · Clientes do v2

2 · Opções do run

Migra medições, ocorrências e manutenções, casando com o cadastro que já existe no v3. Não cria nem altera clientes, equipamentos, tipos, esquemas, alertas ou parâmetros. Equipamento do v2 sem vínculo no v3 fica sem histórico e é listado no fim do run. Re-executar um cliente é seguro: a migração retoma do último checkpoint sem duplicar medições. Paralelismo alto pesa no banco do v2, que está em produção — comece com 1 e suba com cautela.

Cria clientes e equipamentos no v3 — e só isso. Sem device, mapeamento, tipo do v2, esquema, alerta, parâmetro, manutenção ou medição: todo equipamento entra com o tipo genérico (“sem tipo declarado”), sem device vinculado, e é reclassificado depois na UI do v3. Os devices nascem sozinhos no lobby quando o hardware comunica; o vínculo é feito na tela de devices. Re-executar é seguro: cliente e equipamento já existentes são pulados (chave = id do v2), sem tocar em edições feitas à mão. Atenção: equipamento cadastrado manualmente no v3 não tem o id do v2, então o cliente correspondente entraria duplicado — não marque clientes já cadastrados à mão.

Incluir equipamentos inativos: traz também os equipamentos já desativados no v2 (status ≠ 1) dos clientes selecionados, como cadastro apenas. Eles entram visíveis na lista do v3, sem device vinculado — logo não recebem medição nem geram alarme de falta de comunicação — e ficam marcados com a tag legacy-inactive. Nenhum histórico deles migra: sem medições, ocorrências, manutenções, alertas ou parâmetros. Não muda quais clientes são elegíveis: só entram inativos de clientes que já têm equipamento ativo.
Somente os inativos: para clientes cujo cadastro ativo já foi migrado — a fase dos equipamentos ativos nem roda. Ela já seria inofensiva (equipamento com o id do v2 é pulado), mas equipamento cadastrado à mão no v3 não tem esse id e seria recriado; não rodar a fase é a garantia.

3 · Execução

Histórico de execuções