Migrar para Paper costuma parecer uma troca de JAR, mas a versão do servidor e o caminho pelo qual o mundo foi salvo importam. A documentação atual do Paper registra uma diferença relevante a partir da versão 26.1: mundos do Spigot e CraftBukkit usam uma organização própria, então o caminho direto de migração não é suportado nesse cenário.

Este artigo explica como identificar a situação antes de substituir arquivos, o que mudou para Paper 26.1 e como organizar uma saída se você pretende voltar ao Vanilla. Ele não sugere mover pastas no servidor ativo. Sempre preserve os dados e siga os passos oficiais correspondentes ao software e versão que realmente tem em mãos.

Identifique a origem e o destino

Registre o software atual, a versão exata do Minecraft, o nome do mundo em server.properties e quais dimensões e dados de plugins são importantes. Um diretório chamado world não informa sozinho se foi criado por Vanilla, Spigot ou Paper. A história da instalação e os arquivos ao redor ajudam a identificar o formato.

Considere o que precisa ser migrado além de chunks: inventários, entidades, configurações, plugins e bancos externos. Um arquivo de mundo compatível não transfere automaticamente os dados de economia ou permissões de um plugin. Esses componentes precisam de uma migração própria e de um plano de verificação.

Decida se a migração é para Paper, para Vanilla ou entre ambientes que usam plugins e mods. O procedimento não é intercambiável. Também confirme se pretende atualizar ao mesmo tempo para outra versão de Minecraft; combinar essas mudanças multiplica os caminhos possíveis quando algo falha.

Faça um backup e valide uma cópia

Pare a instância corretamente, copie os arquivos necessários e confirme que o backup pode ser restaurado. Mantenha a cópia original intacta. Extraia outra cópia em um ambiente isolado e anote o horário, software, versão e nome do mundo usado.

Não abra o único backup com o destino novo. Um servidor pode converter dados do mundo na inicialização. Uma cópia separada permite descobrir o resultado sem transformar a origem da migração e ainda oferece caminho para repetir o teste.

Inclua dados dos plugins e bancos externos se o plano de migração pretende mantê-los. Restaure esses sistemas em instâncias e bancos de teste próprios. Um Paper de homologação que se conecta ao banco de economia da comunidade ativa pode modificar dados de produção durante um teste aparentemente inocente.

Entenda o que mudou em Paper 26.1

A documentação do Paper distingue a migração de Vanilla da migração de Spigot/CraftBukkit para versões atuais. A partir do Paper 26.1, Spigot e CraftBukkit modificam a estrutura de diretórios de mundos de um modo que torna a migração direta impossível segundo o projeto. Se seu ponto de partida é um desses softwares, use a etapa de conversão para Vanilla descrita na documentação do Spigot antes de continuar com o guia de migração do Paper.

Essa regra não quer dizer que todo mundo com uma pasta world está perdido nem que basta renomear um arquivo. É necessário identificar o software que escreveu a estrutura e seguir o procedimento da origem. Não copie manualmente pastas de dimensão por semelhança visual: um nome igual pode esconder um formato ou dado associado distinto.

Vanilla, Paper e versões diferentes do mesmo projeto também podem armazenar dados em posições distintas. O caminho de Paper para Vanilla inclui movimentações específicas de arquivos de dados para o nome e a estrutura assumidos pelo manual. Esse procedimento é separado do caminho Spigot para Vanilla e deve ser aplicado somente à versão e configuração para as quais foi escrito.

Migrar uma origem Vanilla para Paper

Para uma origem Vanilla compatível, pare o servidor, faça a cópia completa e substitua o servidor pelo Paper da mesma versão-alvo, de acordo com o guia oficial. Preserve o nome de arquivo usado pelo comando de início ou atualize o comando com cuidado. Inicie primeiro a cópia e acompanhe a conversão de dados, em vez de atualizar também o mundo e os plugins de uma vez.

Após a primeira inicialização, confirme que todas as dimensões carregaram e que as coordenadas conhecidas continuam presentes. Entre como um jogador de teste, visite regiões importantes e confira o retorno de Nether e End. Verifique dados de jogador, spawn, regras por mundo e log de inicialização.

Paper introduz a organização de dimensões que permite dados independentes por mundo. A migração pode acontecer automaticamente no caminho descrito pelo projeto, mas o teste ainda precisa verificar o conteúdo real da comunidade. Registre qual versão fez a conversão e preserve a cópia anterior durante a validação.

Migrar de Fabric ou Forge para Paper

Fabric e Forge usam a organização de mundo Vanilla, então o guia de migração correspondente pode servir como base. A limitação decisiva está no conteúdo criado pelos mods. Se o mundo contém blocos, itens ou dados próprios de um mod, Paper não carrega essas funcionalidades porque não executa mods Fabric ou Forge.

Faça uma lista dos mods que alteram geração, blocos, itens, dimensões e dados dos jogadores. Antes de prosseguir, determine como cada dado será exportado, substituído ou preservado. Um mod apenas de desempenho pode ter impacto diferente de um mod que adiciona centenas de blocos usados em construções. Não apague o ambiente original até confirmar o resultado de cada tipo de conteúdo importante.

Não conte com um servidor híbrido que prometa plugins e mods como solução universal. A própria documentação do Paper desaconselha híbridos que tentam misturar esses ecossistemas. Escolha a plataforma com base nos requisitos reais do projeto e encontre substitutos compatíveis antes de modificar o mundo.

Use a rota apropriada para Spigot e CraftBukkit

Para uma origem Spigot/CraftBukkit que vai a Paper 26.1 ou posterior, não faça a troca direta dos arquivos esperando compatibilidade. Consulte o procedimento oficial atual do Spigot para converter o estado para Vanilla. Faça a conversão em uma cópia, verifique se o servidor intermediário inicia e confira os mundos antes de seguir a documentação de Vanilla para Paper.

Essa etapa intermediária tem a finalidade de tratar o formato da origem. A sequência correta pode depender da versão e dos arquivos existentes. Leia integralmente os dois manuais antes de iniciar, porque a preparação para converter e os arquivos a preservar são importantes para o resultado.

Se a documentação da versão atual não cobrir sua combinação específica, não tente adivinhar comandos de conversão. Separe cópia, logs e lista de versões e procure ajuda oficial do projeto. Abrir uma cópia adicional para diagnóstico permite pesquisar sem expor ou alterar o único backup.

Teste antes de aceitar novos dados

  1. Inicie a cópia migrada e guarde o console completo.
  2. Confira cada dimensão, uma construção antiga e regiões com dados especiais.
  3. Entre com contas de teste e confira inventários e dados de jogador.
  4. Execute plugins e integrações individualmente, observando erros e dados persistentes.
  5. Pare e reinicie para verificar que as alterações permanecem corretas.
  6. Compare o estado com o backup e anote limitações conhecidas.

Não permita jogadores no ambiente enquanto esses testes estão em andamento. Um carregamento parcial pode criar novos arquivos, fazendo parecer que uma região ausente foi perdida ou gravando um estado diferente durante a investigação.

Planeje rollback e manutenção

Defina a condição que cancela a migração: dimensão faltante, erro em blocos de mods que não pode ser resolvido, inventários incorretos ou integração essencial sem dados. Para voltar, restaure em conjunto o software, as configurações e os dados preservados. Apenas retornar ao JAR antigo depois de uma conversão não garante que o mundo ficou no formato anterior.

Antes da janela pública, faça um backup novo da produção porque os jogadores continuaram construindo depois da cópia de teste. Registre horário de fechamento, ordem dos passos, versão de Paper e o tempo reservado para conferência. Avise a comunidade se existir risco de rollback ou indisponibilidade.

A migração de hospedagem acrescenta o transporte de arquivos e DNS; mantenha essa atividade separada da conversão do formato do mundo quando puder. O roteiro mais fácil de recuperar é aquele em que cada mudança tem sua própria evidência e cópia de segurança.

Saiba quando não migrar

Adie a troca se a origem não está identificada, o backup não pode ser restaurado ou há conteúdo modificado sem plano de compatibilidade. Um servidor que inicia não prova que a migração preservou tudo. Uma pausa para inventário pode salvar construções, dados dos jogadores e horas de investigação após um retorno mal planejado.

Guarde a combinação que está funcionando e teste primeiro o caminho de conversão em uma cópia separada. Quando as evidências confirmarem compatibilidade, a manutenção pública vira a repetição de um processo conhecido, em vez de uma tentativa feita sobre o mundo original.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.