Blogue ·
Migrar do cPanel para o DirectAdmin
O percurso mais percorrido para sair do cPanel, e o que não transita: regras de nomes, quotas, o identificador que a faturação guarda e cinco armadilhas reais.
Por Provibr
Este é o percurso mais percorrido para sair do cPanel, e percorre-se por uma razão: a licença deixa de crescer com o seu número de clientes. O cPanel Premier cobra 0,49 $ por conta e por mês acima de 100 contas em 1 de janeiro de 2026; o DirectAdmin Standard custa 29 $ por mês para contas ilimitadas, consultado em directadmin.com a 21 de agosto de 2026. A mil contas num servidor, isso dá 510,99 $ contra 29 $.
A poupança é fácil de calcular. O que se segue é a parte que não é: o que tem realmente de acontecer, o que não sobrevive à mudança, e os pontos precisos onde um primeiro script de migração faz discretamente a coisa errada.
O Provibr suporta os dois painéis, e um cliente num ou noutro paga-nos o mesmo. Não temos razão para o convencer a fazer esta mudança, apenas para a tornar exata se a fizer.
Em que consiste realmente uma migração
Quatro coisas, e só a primeira dispõe de boas ferramentas à sua volta.
- Os dados. Ficheiros, bases de dados, correio, zonas DNS. É a parte para a qual os fornecedores escrevem ferramentas de conversão.
- As identidades. Nomes de utilizador, domínios, nomes de pacote. Têm de existir no destino e nem sempre sobrevivem sem alteração.
- A automatização. Tudo o que cria, suspende e fatura as suas contas aponta para o cPanel e tem de apontar para outro lado, em geral enquanto ambos os painéis estão ativos.
- A vaga de tickets. Tudo o que se comportava de uma forma e agora se comporta de outra, a chegar sob a forma de tickets ao longo das duas semanas seguintes.
Não realizámos a sua migração de dados e não vamos descrever a ferramenta de conversão de ninguém como se a tivéssemos testado. Os pontos dois, três e quatro são nossos, porque medimos os dois painéis ao construir integrações contra eles.
A regra dos nomes de utilizador vai renomear alguns dos seus clientes
Ambos os painéis impõem uma forma de nome de utilizador, e não são a mesma forma. A coluna cPanel foi medida criando contas no WHM 11.136 até haver recusa; a coluna DirectAdmin é a regra que a sua própria API impõe.
| cPanel / WHM | DirectAdmin | |
|---|---|---|
| Padrão | ^[a-z][a-z0-9]{0,15}$ | ^[a-z][a-z0-9]{2,15}$ |
| Comprimento | 1 a 16 | 3 a 16 |
| Deve começar por | uma letra | uma letra |
| Hífen | recusado | recusado |
| Sublinhado | recusado | recusado |
| Maiúsculas | convertidas para minúsculas em silêncio | conservadas ou recusadas, nunca reescritas |
| Nomes reservados | sim, com o seu próprio erro (root e outros) | não medido |
A que apanha toda a gente é o mínimo. Uma conta cPanel pode ter um ou dois caracteres; uma conta DirectAdmin não pode. Se tiver alguma dessas (e os alojadores antigos costumam ter um punhado dos primeiros tempos), precisam de um novo nome, o que significa avisar o cliente e atualizar cada referência ao nome antigo.
E há uma armadilha à saída. O WHM aceita um nome de utilizador com maiúsculas, cria-o em minúsculas, e anuncia êxito sem mencionar a alteração. Assim, a conta que julga chamar-se MyClient chama-se myclient no servidor desde o dia em que foi criada. Qualquer inventário que construa para a migração tem de ser lido a partir do servidor e não dos seus próprios registos, sob pena de uma parte dele não corresponder a nada.
O que a sua faturação guarda está prestes a não apontar para nada
Esta é a parte que se subestima, porque é invisível até à transição.
A sua faturação, os seus scripts de aprovisionamento, a sua monitorização e as suas ferramentas de suporte identificam todos uma conta de alojamento por qualquer coisa. No cPanel, essa qualquer coisa é o nome de utilizador. Depois da mudança, continua a ser um nome de utilizador, mas se algum deles foi renomeado, a referência está morta, e uma referência morta num ciclo de cobrança não levanta nenhum erro. Não suspende nada.
Antes de mover uma única conta, produza uma lista com três colunas: o nome de utilizador cPanel, o nome de utilizador DirectAdmin que terá, e o identificador que a sua faturação detém. Se estes três não coincidirem em cada linha, a migração não está pronta, independentemente de como correu a transferência de dados.
Cinco coisas medidas nas duas APIs que vão partir um primeiro script
Tudo isto surgiu da escrita de integrações contra servidores em funcionamento, e as cinco produzem resultados errados em vez de erros.
Ambos os painéis sinalizam a falha com um HTTP 200. o cPanel devolve result: 0 dentro de um objeto metadata; o DirectAdmin devolve error=1 no corpo. Um script que verifica o código de estado vê êxito em cada falha, dos dois lados da mudança. O cPanel tem ainda uma terceira forma: um token errado ou ausente volta como HTTP 403 com um objeto cpanelresult e nenhum metadata, pelo que um analisador que só conhece metadata não consegue distinguir um token errado de um servidor avariado.
O limite de disco "0" do cPanel significa ilimitado, não zero. O mesmo acontece com as cadeias "unlimited" e, para a utilização, "none". Um script de migração que lê a quota de origem como um número e a escreve no destino criará contas sem qualquer espaço em disco para cada cliente ilimitado que tenha, e fá-lo-á sem um único aviso.
O endereço de contacto do cPanel pode ser a cadeia literal "*unknown*". O mesmo para dois ou três dos campos de débito de correio. Copie-a sem verificar e terá criado contas cujo endereço de contacto é um marcador de posição, o que se descobre quando o primeiro aviso de suspensão não chega a lado nenhum.
A pesquisa de contas do cPanel é uma correspondência de subcadeia, não uma correspondência exata. Pedir provibrtest1 devolveu tanto provibrtest1 como provibrtest12345. Se a sua migração verifica cada conta depois de a mover, pesquisando o seu nome no painel de origem, pode confirmar a conta errada e marcar como migrado um cliente que não o está. É preciso filtrar exatamente pelo nome de utilizador.
Um servidor cPanel sem contas não devolve uma lista vazia. Omite por completo a chave de dados. Um script que trata uma chave em falta como uma falha assinalará como erro o seu último servidor, esvaziado com êxito; um script que a trata como «nenhuma resposta recebida» é pior, porque num servidor ativo essa é a diferença entre «esta conta desapareceu» e «não conseguimos dizer».
Do lado do DirectAdmin, há mais dois pontos que vale a pena conhecer. A sua lista de utilização acusa um atraso de cerca de três segundos face às criações e eliminações, pelo que um passo de verificação que corre logo a seguir a uma criação não vê nada e conclui que a conta não foi criada. Utilize antes a lista de contas que faz autoridade. E o texto de confirmação da reativação de uma conta diz literalmente «have been suspended», o que importa precisamente durante uma transição, quando suspender num painel e reativar no outro são as duas metades de cada movimento.
O que não transita
Para além dos próprios dados:
| O que acontece | |
|---|---|
| Pacotes | Não portáveis. Recriam-se à mão no DirectAdmin, e os limites que contêm ficam a seu cargo para os manter em sintonia. |
| Domínios adicionais e estacionados | O cPanel indica os domínios principais, adicionais, subdomínios e estacionados por conta. O DirectAdmin cria uma conta com um domínio; os restantes acrescentam-se depois dentro do painel. Qualquer automatização tem de saber qual é o principal. |
| Contadores de largura de banda | Totais mensais que o próprio servidor repõe a zero. Não migram, e o primeiro mês após uma migração mostra-se baixo no novo painel e alto no antigo. |
| Motivos de suspensão | O texto é devolvido em eco no cPanel e guardado por conta. Preveja voltar a registar porque está suspenso aquilo que está suspenso. |
| Tudo o que chamava a API do cPanel | Scripts destinados aos clientes, hooks, extensões de terceiros. Não têm equivalentes DirectAdmin por predefinição. |
| Quotas de disco que nunca foram aplicadas | Ver mais abaixo. Esta é uma vaga de tickets, não um problema de dados. |
A armadilha das quotas, e porque surge na primeira semana
Um servidor cPanel só aplica as quotas de disco quando o sistema de ficheiros onde residem as contas suporta quotas. Sem isso, o WHM aceita o pacote, aceita o número, e não aplica nada. Medimos exatamente isto num servidor WHM 11.136 em funcionamento: uma conta movida para um pacote com uma quota de 2 GB continuou a anunciar o seu limite como unlimited, e os valores de disco por conta vinham vazios. Nada falhou e nada foi recusado.
Se esse é o estado do seu parque, cada conta esteve de facto com disco ilimitado durante todo o tempo em que isso foi verdade. E algumas terão crescido muito para além do que lhes vendeu. Passe para um painel que, esse sim, aplica a quota que configurou, e todas batem no muro na mesma semana.
Verifique isto antes de planear a migração, não durante. Se as quotas não estão a ser aplicadas, há uma decisão a tomar sobre as contas em excesso (aumentá-las, contactá-las ou tarifá-las) e é uma decisão muito melhor de tomar com antecedência do que numa fila de tickets.
O teste de ligação do Provibr indica se as quotas estão realmente a ser aplicadas num servidor cPanel, a par da versão e das contagens de contas, o que é uma forma económica de o saber. É também por isso que a plataforma lê o limite de disco de uma conta a partir da conta e não do pacote: o que a conta anuncia é o que está em vigor.
Faça-o por coortes, e conte com meses
O padrão que funciona é aborrecido e é o único que funciona.
Dirija primeiro as novas encomendas para o DirectAdmin. Nada precisa de migrar para isso, o painel de destino é posto à prova em condições reais, e aprende-se o seu comportamento em contas de que ninguém depende há anos.
Depois, mova as contas com a pior relação entre licença e receita. Os seus planos mais baratos, cujos clientes menos se importam com a interface.
Depois, tudo o resto, em lotes que consiga suportar. Uma dimensão de lote em que uma má tarde seja recuperável, o que, para a maioria dos alojadores, é menor do que planeiam à partida.
Mantenha o painel antigo até que a última conta o tenha deixado e tenha decorrido um ciclo de faturação completo. O mês a seguir a uma migração é aquele em que o contador se repõe a zero, as faturas saem e as discrepâncias aparecem.
Os meses intermédios
Durante todo esse período opera dois painéis. Dois inícios de sessão, duas formas de contar o que vendeu, dois sítios onde olhar quando um cliente telefona, e dois conjuntos de automatização que têm de concordar sobre quem está suspenso. Esse período é o verdadeiro custo da mudança, e é a razão pela qual muitos alojadores decidem migrar e depois nunca começam.
O Provibr liga ambos os painéis à mesma conta. Uma conta cPanel e uma conta DirectAdmin figuram na mesma lista de servidores, contam para a mesma capacidade e chegam à mesma fatura mensal, com as mesmas ações por trás: suspender, reativar, mudar de pacote e eliminar. O agente estabelece a ligação para o exterior a partir da sua própria rede, pelo que nenhum dos servidores precisa de ter uma porta de entrada aberta e nada é instalado em qualquer um deles. As contas que não criou através do Provibr são deixadas intactas até que as importe, pelo que um painel que já tem quatrocentas contas se torna algo que adota em vez de algo que reconstrói.
Não move os seus dados. Remove a razão para adiar a sua deslocação.
A ler a seguir
- DirectAdmin vs cPanel: os números de 2026: a curva de custo por conta e nove diferenças operacionais.
- O aumento de preços do cPanel em 2026: a aritmética por dimensão de parque e as quatro saídas.
- Configurar o DirectAdmin: chaves de início de sessão, pacotes, planos web e importação de contas.
Os preços públicos do cPanel de 2026 provêm da cobertura pública do anúncio em vigor a 1 de janeiro de 2026; os preços do DirectAdmin foram consultados em directadmin.com a 21 de agosto de 2026. Cada comportamento de API aqui descrito foi medido em servidores cPanel e DirectAdmin em funcionamento durante a construção das integrações Provibr. Não se faz qualquer afirmação sobre a ferramenta de conversão de dados de nenhum fornecedor, que não testámos.