Migração e atualização do DSpace: como mudar de plataforma ou sair de uma versão antiga

O que se migra, o que se reconstrói e o que se perde

Um repositório não é um único banco de dados: são quatro camadas, com formatos e riscos diferentes. O erro de planejamento mais comum é orçar a "migração do repositório" pensando apenas nos metadados.

• Metadados descritivos: a descrição de cada item, normalmente em Dublin Core qualificado. É o que viaja em XML ou CSV e o que se mapeia campo a campo.
• Bitstreams: os arquivos em si, como o PDF da tese, o dataset ou o áudio. No DSpace eles ficam no assetstore, fora do banco de dados, e precisam ser movidos à parte.
• Estrutura de comunidades e coleções: a árvore de faculdades, programas e tipos documentais. Ela é reconstruída no destino antes de qualquer carga, porque cada item precisa de uma coleção de chegada.
• Identificadores persistentes: os handles ou DOIs já publicados. É a única camada que, se quebrar, quebra também tudo o que está fora do repositório.

Há coisas que não se migram, e sim se reconstroem: os fluxos de depósito e revisão, os grupos e permissões, os formulários de submissão, os embargos configurados como políticas de acesso e a personalização visual. E há uma camada que quase nunca se migra por completo: o histórico de estatísticas de uso, que fica em um núcleo do Solr e só pode ser transferido quando a origem também é DSpace.

Identificadores persistentes: o ponto que não pode quebrar

O DSpace atribui a cada item um handle, um identificador no formato hdl.handle.net/prefixo/sufixo. O prefixo é emitido pela CNRI para a instituição mediante uma taxa anual, e a promessa do sistema é que essa URL continue resolvendo mesmo que mudem o domínio, o servidor ou a plataforma. Se o repositório anterior já publicou identificadores que aparecem em teses, artigos e currículos, é preciso levá-los junto. Há dois caminhos, e a escolha deve ser feita no início do projeto, não no fim:

• Transferir o prefixo: combina-se com a CNRI que a resolução do prefixo existente passe a apontar para o servidor novo. É a opção limpa, mas é tudo ou nada: o prefixo inteiro vai para o repositório novo e a plataforma anterior deixa de resolver os handles restantes.
• Manter o identificador antigo como metadado e publicar redirecionamentos a partir das URLs antigas. É a saída quando o prefixo pertence a um consórcio ou a um fornecedor que não o cede.

Se a origem usava DOIs da DataCite, a operação é equivalente: atualizar a URL de destino registrada para cada DOI. É um trabalho mecânico e massivo, mas não opcional.

Formatos de entrada: o que o DSpace aceita

Cada porta de entrada do DSpace serve a um cenário diferente:

Dois alertas aparecem em quase todos os projetos. O pacote ZIP enviado pela interface tem limite de 2 GB por padrão, então um repositório com milhares de PDFs é carregado em lotes ou pela linha de comando. E um CSV editado no Excel costuma chegar com os acentos quebrados, porque o Excel lida mal com UTF-8 e insere uma marca invisível no início do arquivo.

Cenários de migração: dificuldade e o que se preserva

O último cenário é o mais comum nas universidades latino-americanas e o que pior se orça, porque parece o mais simples. Não é: a dificuldade sai do código e vai para a instituição. É preciso decidir o que se publica, obter a autorização dos autores, definir licenças, montar a árvore de comunidades e, sobretudo, evitar que o repositório nasça vazio. Foi exatamente o problema resolvido na Universidad Americana, do Paraguai, onde a BiblioLabTech integrou a extração automática de metadados ao fluxo de depósito para que preenchê-lo não dependesse de transcrever cada documento à mão. Toda implantação de DSpace da BiblioLabTech inclui a MetaExtract API sem custo adicional.

Migração e atualização do DSpace em sete passos

A ordem importa: pular o ambiente espelho é o atalho que sai mais caro.

1. Inventário da origem. Quantos itens, quantos bitstreams e quantos gigabytes; que esquema de metadados e que versão exata do sistema; se há acesso ao banco de dados ou só a uma exportação; que identificadores foram publicados e quem controla o prefixo.
2. Mapeamento de metadados campo a campo para o registro do DSpace. Aqui se decide o que vai para o Dublin Core padrão e o que vai para o esquema local, onde devem ficar os campos próprios para que nenhuma atualização futura os afete.
3. Desenho de comunidades e coleções no destino, com os tipos de item, os formulários de depósito e as políticas de acesso já definidos.
4. Carga de teste em um ambiente espelho, idêntico ao de produção, com um lote piloto de 100 a 500 itens representativos: uma tese com embargo, um artigo com vários autores, um item com cinco arquivos, um com caracteres especiais no título e um de cada coleção problemática.
5. Validação com a equipe da biblioteca no repositório real, não em uma planilha: buscar por autor, filtrar por facetas, abrir o PDF, confirmar que o embargo bloqueia o download.
6. Carga completa e congelamento. Data e hora a partir das quais nada mais é depositado no sistema anterior, carga total, conferência de contagens (itens por coleção, bitstreams por item, soma de tamanhos) e migração do delta entre o dump e o congelamento.
7. Corte e verificação de identificadores. Aponta-se o domínio, abre-se o repositório e verifica-se que handles e DOIs resolvem, com amostra manual e revisão automatizada da lista completa. É a última entrega, não uma pendência.

Nos nossos projetos, uma migração com exportação em formato padrão e com a biblioteca participando da validação leva entre quatro e dez semanas de trabalho efetivo para um repositório de alguns milhares de itens. O que move esse intervalo não é o número de itens, e sim a qualidade dos metadados de origem, o volume em gigabytes e o número de decisões que a instituição ainda não tomou. O orçamento correspondente está em quanto custa um repositório DSpace.

Atualização do DSpace 6 ou 7 para uma versão com suporte

Não é uma troca de plataforma, mas se parece com uma. O ponto de partida é a política de suporte: a comunidade mantém as três últimas versões principais. Com o DSpace 10.0, lançado em 28 de maio de 2026, as séries com suporte passaram a ser 8.x, 9.x e 10.x; a 7.x encerrou o ciclo com a versão 7.6.7 e a 6.x já estava fora de suporte. A versão mais recente é a 10.1, de setembro de 2026. Atualizar para uma série perto do fim da vida útil é pagar duas vezes pelo mesmo trabalho, então o destino recomendado hoje é a série 10.x.

Vale um alerta para o Brasil: o roteiro de instalação publicado pelo Ibict, que promove o DSpace no país, ainda descreve a versão 6.3, com a interface JSPUI, Java 8 e Tomcat 8. Se o seu repositório nasceu desse roteiro, ele roda em uma linha que a comunidade já não corrige, e a atualização envolve trocar praticamente toda a pilha. Quatro mudanças pesam.

A nova pilha técnica

O DSpace 10 exige o JDK 21 e pode rodar como JAR com Tomcat embutido; o frontend exige Node.js 20.19 ou superior, e o Solr precisa ser da série 9 desde o DSpace 9. Muitas vezes, o caminho mais limpo é montar um servidor novo e desligar o antigo depois da validação.

O salto de interface

Desde o DSpace 7, as interfaces XMLUI e JSPUI desapareceram, e todo o frontend é uma aplicação Angular independente do backend. Nenhuma personalização de tema feita sobre as interfaces antigas é migrada: ela é refeita. Convém orçar essa parte como desenvolvimento, não como configuração.

O registro de metadados e as entidades

O DSpace 7 introduziu o modelo de entidades e relacionamentos, que guarda os vínculos em uma tabela própria. Não existe um script que converta em bloco os itens antigos em entidades, então a recomendação, da comunidade e nossa, é separar os dois projetos: primeiro a atualização técnica, com as entidades desativadas, e depois a adoção do modelo. Uma regra evita dores futuras: não se editam os esquemas dc e dcterms; campos próprios vão para o esquema local.

As estatísticas

As estatísticas de uso e o núcleo de autoridades são exportados e importados explicitamente; os núcleos de busca e de OAI são reconstruídos com reindexação. Se as estatísticas antigas estavam fragmentadas por ano, há trabalho adicional, porque as versões modernas não lidam com essa fragmentação.

O que costuma dar errado

• Handles quebrados: o repositório abre e as citações publicadas deixam de resolver. É o único erro que prejudica quem nem trabalha na biblioteca.
• Backup incompleto antes do corte: salva-se o banco e esquece-se o assetstore, ou o contrário.
• Acentos quebrados e itens sem bitstream: detectam-se conferindo contagens, e não revisando a olho.
• Embargos não transferidos, que publicam em aberto uma tese restrita. É a falha com consequências legais.
• Coleções inventadas durante a carga e sistema anterior não congelado, que deixam dois repositórios divergentes por semanas.

Depois do corte

Um repositório migrado não está pronto no dia em que abre. Restam três frentes. A primeira é a visibilidade: configurar os contextos OAI-PMH para que os agregadores possam coletá-lo, o que exige cumprir as suas diretrizes de metadados, e não só ligar o servidor OAI. No Brasil, isso significa confirmar que o Oasisbr continua coletando o endereço certo e, para teses e dissertações, que a BDTD do Ibict segue recebendo os registros. A segunda é a infraestrutura: onde a instância vai rodar, com que política de backups e quem aplica as correções; tratamos disso em hospedagem DSpace: nuvem gerenciada ou servidor próprio.

A terceira é estratégica. Se a universidade precisa responder o que produziu o pesquisador X ou o que saiu do projeto financiado Y, o repositório de documentos não basta, e a conversa passa para o DSpace-CRIS. Vale levantar o tema antes de migrar, porque decidi-lo a tempo muda a forma de modelar coleções e metadados de autoria.

Na Escuela Colombiana de Ingeniería Julio Garavito, o repositório DSpace convive com o catálogo Koha e com o restante da plataforma da biblioteca, porque foi planejado como um sistema, e não como uma compra isolada. Se você precisa migrar ou atualizar um repositório e quer uma proposta com inventário, mapeamento, ambiente de teste e verificação de identificadores incluídos, a BiblioLabTech orça o projeto sobre os números reais do seu acervo pelo nosso serviço de implantação de DSpace.

O DSpace é software livre mantido pela sua comunidade internacional, com a LYRASIS como organização anfitriã, em dspace.org.