É preciso distinguir duas coisas que a pergunta confunde. A ESTRUTURA do seu livro, sim: anexe o ficheiro .xlsx ou .csv à sua descrição, as colunas e folhas são lidas e transformam-se em campos e entidades no plano que aprova antes da construção. As suas LINHAS, não: não existe um ecrã universal de importação; a aplicação é entregue com dados de demonstração e os seus dados operacionais são reintroduzidos quer manualmente, apenas no perímetro realmente útil, quer de uma só vez através da base de dados, uma base PostgreSQL padrão que lhe pertence. No sentido inverso, porém, a saída é imediata: exportação CSV a partir de cada lista e exportação JSON de todos os conjuntos de dados.
A estrutura, sim, o seu livro é lido
Um livro de gestão contém já uma aplicação em embrião: as folhas são entidades, as colunas copiadas de uma folha para outra são relações e os códigos «OK / em curso / atrasado» são estados. Não precisa de traduzir nada disto sozinho: o ficheiro .xlsx ou .csv anexa-se diretamente à sua descrição, é lido e o seu conteúdo alimenta a geração do plano.
Esse plano é-lhe apresentado ANTES de qualquer coisa ser construída e pode ser editado: renomear um campo, remover uma coluna que era apenas uma cópia, corrigir a lista de estados. É aqui que se define a fidelidade ao seu modo de trabalhar, não depois.
As suas linhas, não, e é melhor dizê-lo claramente
Atualmente, não existe um ecrã universal «importe o seu ficheiro» nas aplicações geradas. A aplicação é entregue com dados de demonstração realistas, concebidos para que possa avaliar a ferramenta com base em exemplos concretos; estes não são os seus dados e são eliminados. Existe uma exceção: as entidades de MEDIÇÃO, leituras, séries de sensores, trajetórias, têm uma rota de importação de ficheiros, porque uma medição entra sempre por ficheiro e nunca por formulário.
Para todo o resto, há duas vias. A reintrodução manual no perímetro útil, que é muito mais curta do que parece (veja a secção seguinte). Ou o carregamento de uma só vez através da base de dados: trata-se de uma base PostgreSQL padrão gerida pelo Prisma, e o código da aplicação é seu, logo um programador, ou você mesmo, caso se sinta à vontade, pode carregar um ficheiro CSV com um pequeno script. Isto não é fornecido «pronto a usar», mas é simplesmente possível, ao contrário do que acontece numa ferramenta fechada, onde a base de dados nunca lhe é mostrada.
O histórico útil é menor do que imagina
O receio de «perder tudo» parte do pressuposto de que é necessário reintroduzir tudo. Na prática, o que serve no dia a dia é o conjunto em curso: processos abertos, clientes ativos, stock real. O restante é arquivo, e um arquivo não precisa de viver dentro da ferramenta de trabalho, o livro de Excel passado para modo de leitura preserva-o perfeitamente e continua acessível.
Assim, a migração bem-sucedida é progressiva: novos casos na aplicação já na primeira semana, os registos ativos reintroduzidos a seguir e o livro convertido em arquivo imutável no final. Trata-se de um trabalho de algumas noites, não de um projeto, e tem a vantagem de o obrigar a rever cuidadosamente o que está a transportar, em vez de duplicar dez anos de informação desatualizada.
No sentido inverso: extrair os seus dados, imediatamente
A questão da importação esconde outra, mais importante: será possível retirar-se do serviço com os seus dados? Cada lista da aplicação inclui um botão para exportar em CSV as linhas visíveis, filtros incluídos, num formato que o Excel abre corretamente em português, com ponto-e-vírgula como separador e codificação preservada, sem necessidade de ajustes manuais. As definições da aplicação oferecem ainda uma exportação JSON de cada conjunto de dados.
Acresce o que verdadeiramente a distingue: o código da aplicação exporta-se como um ficheiro ZIP ou envia-se diretamente para o GitHub, e a base de dados é sua. Uma ferramenta da qual pode sair em três cliques não precisa de o reter: este é o melhor teste a aplicar a qualquer software antes de nele depositar os seus dados.