Toda empresa que ainda roda um servidor de arquivos local sabe que ele funciona. Mais ou menos. O problema não é que ele para de funcionar de repente. É que ele vai ficando invisível, acumulando pastas que ninguém sabe quem criou, permissões herdadas de funcionários que saíram há três anos e backups que o time de TI torce para nunca precisar testar de verdade.

Quando alguém finalmente decide migrar servidor de arquivos para SharePoint, o impulso natural é copiar tudo e resolver depois. Na minha experiência, esse ‘depois’ nunca chega. E aí a nuvem vira um espelho fiel do caos que já existia, só que agora com custo mensal de licença.

Este artigo é para quem quer fazer essa transição direito. Sem romantismo, sem promessa de que vai ser indolor, mas com um roteiro que funciona na prática para empresas brasileiras de médio e grande porte.

Antes de migrar qualquer arquivo: entenda a diferença entre OneDrive e SharePoint

Parece óbvio, mas a quantidade de projetos que tropeçam aqui é impressionante. OneDrive e SharePoint vivem dentro do Microsoft 365 e compartilham a mesma infraestrutura de armazenamento, mas têm propósitos bem diferentes.

OneDrive corporativo: a gaveta pessoal do colaborador

O OneDrive corporativo é o espaço individual. Pense nele como a pasta ‘Meus Documentos’ de cada usuário, só que na nuvem. Rascunhos, anotações de reunião, aquele arquivo que a pessoa ainda está trabalhando antes de compartilhar com o time. Cada licença de Microsoft 365 Business ou Enterprise dá 1 TB por usuário (em alguns planos, até ilimitado, embora a Microsoft tenha apertado as regras de uso justo nos últimos anos).

O ponto é: se o arquivo pertence a uma pessoa e ninguém mais precisa dele no dia a dia, OneDrive. Simples.

SharePoint para empresas: o arquivo é do time, não da pessoa

O SharePoint para empresas (e por extensão, os arquivos dentro do Microsoft Teams) é onde ficam os documentos que pertencem a um departamento, a um projeto, a uma área. Contratos do jurídico, materiais de marketing, documentação técnica de produto, planilhas financeiras consolidadas.

Quando alguém sai da empresa, os arquivos do OneDrive pessoal têm um prazo de retenção e depois somem (a menos que o gestor tome uma ação). Já o que está no SharePoint continua lá, porque pertence à organização. Essa distinção parece pequena até o dia em que um gerente de projeto pede demissão e leva junto, sem querer, toda a memória de um projeto de seis meses.

O erro mais caro: replicar a estrutura do file server na nuvem

Se eu pudesse dar só um conselho para quem vai migrar, seria este: não copie a árvore de pastas do servidor antigo para o SharePoint.

Sério. Aquela estrutura nasceu organicamente ao longo de anos, talvez décadas. Tem pasta chamada ‘Novo’, ‘Novo2’, ‘Antigo (não apagar)’, ‘Backup João’, ‘Público’. Tem subpasta dentro de subpasta dentro de subpasta até atingir limites de caminho que o Windows nem consegue abrir direito.

Migrar isso para a nuvem não é modernizar. É empacotar bagunça com fita adesiva bonita.

Como desenhar a estrutura certa antes de mover um byte

O trabalho chato acontece antes da migração. E é justamente o trabalho que todo mundo quer pular.

1. Mapeie as áreas da empresa que realmente precisam de espaço compartilhado. Financeiro, RH, Comercial, Operações, Projetos. Cada uma vira um site do SharePoint (ou um Team no Microsoft Teams, que cria um site do SharePoint por baixo dos panos).
2. Dentro de cada site, defina bibliotecas de documentos por função, não por pessoa. ‘Contratos’, ‘Relatórios Mensais’, ‘Políticas Internas’, e não ‘Pasta da Maria’ ou ‘Coisas do Pedro’.
3. Permissões por grupo do Azure AD (Entra ID), nunca por usuário individual. Quando a Maria trocar de área, você ajusta o grupo e todas as permissões se propagam. Sem ticket, sem planilha de controle manual.
4. Defina uma política de nomenclatura de sites. Parece burocracia, mas quando você tem 200 sites do SharePoint sem padrão nenhum, encontrar qualquer coisa vira uma operação de busca e salvamento.

E aquela pasta ‘Público’ que existe desde 2012, com 800 GB de arquivos que ninguém sabe se ainda servem para alguma coisa? Ela não entra na nova estrutura. Ponto. Coloque em quarentena, avise os donos das áreas, dê um prazo para reivindicar o que for importante. O que ninguém reivindicar em 90 dias provavelmente não faz falta.

Ferramentas de migração: o que usar e o que esperar

A Microsoft oferece duas ferramentas gratuitas para quem vai fazer a migração dentro do ecossistema dela. Não são perfeitas, mas resolvem bem a maioria dos cenários.

SharePoint Migration Tool (SPMT)

É um aplicativo desktop que você instala em uma máquina com acesso ao file server local e ao tenant do Microsoft 365. Ele lê os compartilhamentos de rede (ou pastas locais), mapeia para bibliotecas do SharePoint ou contas do OneDrive e faz a cópia preservando timestamps e, na maioria dos casos, as permissões NTFS (que precisam de mapeamento manual para grupos do Azure AD).

Funciona bem para migrações de até algumas centenas de milhares de arquivos. Para volumes maiores, tende a ficar lento e é melhor partir para o Migration Manager.

Migration Manager

Roda direto no admin center do SharePoint Online. Você instala um agente leve na máquina que tem acesso ao file server e gerencia tudo pela interface web. A vantagem é a escalabilidade: dá para rodar múltiplos agentes em paralelo e acompanhar o progresso de um painel centralizado.

Para quem tem mais de um servidor em filiais diferentes, o Migration Manager é o caminho. Ele também gera relatórios de erros detalhados, o que facilita demais a vida na hora de resolver aqueles arquivos com nomes impossíveis ou caminhos longos demais.

Existem ferramentas de terceiros também (ShareGate, AvePoint, BitTitan), que fazem sentido quando a migração envolve volumes muito grandes, mapeamento complexo de permissões ou migração de outros sistemas como Google Drive, Dropbox Business ou servidores NAS com estruturas fora do padrão.

Limites técnicos que poucas pessoas leem antes de migrar

Essa parte não é glamourosa, mas ignorar esses limites é o que transforma uma migração planejada em uma semana de chamados no helpdesk.

Caminho completo do arquivo: máximo de 400 caracteres

O SharePoint Online aceita caminhos de até 400 caracteres (URL completa, incluindo o nome do site, biblioteca, pastas e nome do arquivo). Parece muito até você considerar que a URL do SharePoint já consome uns 80 caracteres antes de chegar na primeira pasta. Aquela estrutura com seis níveis de subpasta e nomes descritivos tipo ‘Relatório Consolidado Mensal – Versão Final Revisada (aprovado pelo diretor).xlsx’ vai estourar o limite. E quando estoura, o arquivo simplesmente não sobe.

Antes de migrar, rode um scan nos arquivos do servidor (o próprio SPMT faz isso) e identifique os caminhos longos. Renomear antes é mais barato do que descobrir depois.

Tipos de arquivo bloqueados e tamanhos

O limite de tamanho por arquivo no SharePoint e OneDrive é de 250 GB (subiu bastante nos últimos anos). Na prática, porém, arquivos acima de 10-15 GB já causam problemas de sincronização no client do OneDrive e podem travar a experiência do usuário.

Alguns tipos de arquivo são bloqueados: .exe, .dll, .aspx e outros que representam risco de segurança. Arquivos temporários (~$nomedoarquivo) também são ignorados. Se o seu servidor tem muita coisa legada nesses formatos, é hora de decidir o que realmente precisa vir junto.

O que não deve ir para o SharePoint (mesmo que caiba)

Nem tudo que está no file server pertence ao SharePoint. Esse é um ponto que muita gente erra por pressa ou por achar que a nuvem resolve qualquer coisa.

Bases de dados de sistemas legados (aquele arquivo .mdb do Access que o financeiro ainda usa, ou o banco SQLite que alimenta um sisteminha interno) não funcionam bem no SharePoint. O SharePoint não é um servidor de banco de dados. Colocar um .mdb lá e tentar abrir com múltiplos usuários simultâneos é receita para corromper o arquivo.

Arquivos muito grandes de CAD, vídeo bruto de produção ou imagens médicas em DICOM também pedem uma conversa mais honesta. Não que o SharePoint não aceite (dentro do limite de 250 GB por arquivo), mas a experiência de abrir, editar e salvar esses arquivos pela nuvem é sofrível em muitos cenários, especialmente em links de internet que não são fibra dedicada. Para esses casos, vale considerar o Azure Files ou até um NAS local com backup na nuvem, dependendo do perfil de uso.

Se a sua empresa tem esse tipo de acervo pesado, a solução é híbrida. Migra para o SharePoint o que faz sentido (documentos Office, PDFs, imagens leves, planilhas) e trata o resto com uma estratégia separada. Querer forçar tudo numa plataforma só é o tipo de decisão que volta para assombrar seis meses depois.

Versionamento e retenção: o seguro que o file server nunca teve

Uma das maiores vantagens do SharePoint sobre o file server tradicional (e que surpreendentemente pouca gente aproveita direito) é o versionamento nativo. Toda vez que alguém salva um arquivo, o SharePoint mantém a versão anterior. Por padrão, são 500 versões por arquivo, o que é um exagero para a maioria dos cenários e pode consumir espaço de armazenamento de forma inesperada.

Na prática, recomendo configurar entre 50 e 100 versões principais e revisar essa política por biblioteca. Documentos que mudam muito (planilhas colaborativas, por exemplo) se beneficiam de mais versões. Políticas internas que mudam uma vez por ano não precisam de 500 cópias.

Já a retenção é outra camada. Com as políticas de retenção do Microsoft 365 (configuradas no Purview, antigo Compliance Center), você define por quanto tempo cada tipo de documento precisa ser mantido, mesmo que o usuário delete. Isso é ouro para quem precisa atender requisitos da LGPD (Lei 13.709/2018), auditorias internas ou regulações setoriais.

Um exemplo concreto: contratos precisam ficar retidos por 5 anos após o encerramento. Você cria um rótulo de retenção, aplica na biblioteca ‘Contratos’ do site do Jurídico e pronto. Se alguém tentar apagar antes do prazo, o sistema impede. Tente fazer isso num file server tradicional sem um software de terceiros. Boa sorte.

Rótulos de sensibilidade: classificar antes que o auditor pergunte

Esse assunto conecta governança de arquivos com segurança da informação, e é onde muitas empresas descobrem que migrar para a nuvem trouxe visibilidade sobre problemas que já existiam mas ninguém via.

Os rótulos de sensibilidade do Microsoft 365 para empresas permitem classificar documentos como ‘Público’, ‘Interno’, ‘Confidencial’ ou ‘Altamente Confidencial’ (os nomes são customizáveis). Cada rótulo pode aplicar automaticamente criptografia, marca d’água, restrição de compartilhamento externo e até impedir cópia para dispositivos não gerenciados.

Para o DPO da empresa, isso é um salto enorme. Em vez de confiar que ninguém vai compartilhar a planilha de salários por e-mail (spoiler: alguém vai), o rótulo garante que o arquivo só abre em dispositivos corporativos e não pode ser encaminhado para fora da organização.

Implementar rótulos de sensibilidade junto com a migração é o cenário ideal. Você já está mexendo na estrutura, já está conversando com as áreas sobre o que é de quem. Aproveitar esse momento para classificar os documentos mais sensíveis evita ter que fazer o mesmo exercício seis meses depois, quando todo mundo já esqueceu.

E aqui vale conectar com outra preocupação legítima: se a governança dos dados preocupa, investir em cibersegurança corporativa na camada de identidade e acesso é tão relevante quanto organizar as pastas.

O plano de migração na prática: fases que funcionam

Migração de file server não é um evento de fim de semana. É um projeto que, dependendo do tamanho da empresa, pode levar de 4 a 12 semanas. A boa notícia é que dá para fazer em fases, sem desligar o servidor antigo de uma vez.

Fase 1: Inventário e limpeza (semanas 1-2)

Rode o scan do SPMT ou do Migration Manager para ter um raio-x do que existe no servidor. Quantidade de arquivos, tamanho total, caminhos longos, tipos bloqueados, arquivos não acessados há mais de 2 anos.

Na maioria das empresas que já vi, entre 30% e 50% dos arquivos no file server não foram acessados nos últimos 24 meses. Migrar isso tudo é jogar dinheiro fora (sim, armazenamento do SharePoint Online tem limite por tenant, e estouro custa caro).

Fase 2: Desenho da estrutura no SharePoint (semanas 2-3)

Crie os sites, as bibliotecas e os grupos de permissão no Azure AD (Entra ID). Documente a estrutura. Parece burocracia, mas esse documento vira a referência para o time de TI e para os gestores das áreas nos meses seguintes.

Fase 3: Migração piloto com uma área (semanas 3-5)

Escolha uma área que seja colaborativa mas não crítica demais. Marketing costuma ser uma boa candidata: muitos arquivos, equipe que costuma ser receptiva a mudanças e, se algo der errado, não para a operação da empresa. Migre, teste, colete feedback, ajuste.

Fase 4: Migração das demais áreas em lotes (semanas 5-10)

Com as lições do piloto, migre as demais áreas em lotes. Financeiro e RH por último, porque geralmente têm os requisitos de permissão mais rígidos e os dados mais sensíveis.

Fase 5: Descomissionamento do file server (semanas 10-12)

Não desligue o servidor no dia seguinte à migração. Mantenha ele em read-only por pelo menos 30 dias. Se ninguém reclamar que falta alguma coisa, aí sim é seguro desligar. (E quando desligar, lembre de pensar no descarte certificado de equipamentos do hardware que vai sair do rack.)

Quanto custa manter os arquivos no SharePoint Online?

Cada tenant de Microsoft 365 recebe 1 TB de base mais 10 GB por licença adquirida. Numa empresa com 200 licenças, isso dá 3 TB de armazenamento do SharePoint. Para muitas empresas de médio porte, é suficiente. Para quem tem acervos maiores, a Microsoft vende armazenamento adicional por GB/mês, e o preço pode surpreender quem não fez a conta antes.

A dica prática: a limpeza da Fase 1 não é frescura. Cada GB de lixo que você não migra é dinheiro que não gasta todo mês.

E tem outro custo que ninguém contabiliza: o custo de não migrar. Manter um servidor físico liga a conta de energia, contrato de suporte, backup em fita ou disco externo, alguém para monitorar e eventualmente trocar disco quando falha. Na maioria dos casos, o custo total de propriedade do file server local é maior do que o do SharePoint, especialmente quando você coloca na conta o risco de perda de dados. Se você quiser entender melhor a importância de ter um plano de backup para Microsoft 365, vale a leitura.

O SharePoint pode substituir completamente o file server?

Para 80% dos cenários de uma empresa típica de serviços, sim. Documentos do Office, PDFs, imagens, planilhas, apresentações. Tudo isso roda muito bem no SharePoint e no OneDrive, com a vantagem de acesso remoto nativo, coautoria em tempo real e busca que realmente funciona (o servidor de arquivos nunca teve uma busca decente, convenhamos).

Para os outros 20%, a resposta é: depende. Se você tem bancos de dados Access compartilhados, aplicações legadas que gravam em diretório de rede, arquivos gigantes de engenharia ou processos que dependem de scripts mapeando unidades de rede com letra de drive, vai precisar de uma estratégia complementar. Azure Files, Azure Blob Storage ou até manter um servidor local menor só para esses casos específicos são caminhos válidos.

O erro é tratar a migração como tudo ou nada. Migre o que faz sentido para o SharePoint e trate as exceções como exceções, com soluções adequadas para cada uma.

Governança pós-migração: o trabalho que nunca acaba

Migrar é metade da batalha. A outra metade é garantir que a estrutura não se deteriore com o tempo (porque vai, se ninguém cuidar).

Defina donos para cada site do SharePoint. Não o TI, mas o gestor da área. O diretor do Jurídico é responsável pelo site do Jurídico, o gerente de Marketing pelo site de Marketing. O TI fornece a plataforma e as políticas, mas quem decide o que fica e o que vai embora é a área de negócio.

Revise permissões trimestralmente. O SharePoint tem relatórios nativos de acesso e compartilhamento. Use. Aquele link de compartilhamento ‘qualquer pessoa com o link’ que o estagiário criou há seis meses para enviar um arquivo para o fornecedor ainda está ativo? Provavelmente está.

Configure alertas de armazenamento. Quando um site atingir 80% da cota, alguém precisa saber antes que os usuários comecem a receber erro ao salvar arquivo.

Quando faz sentido trazer ajuda de fora

Se a sua empresa tem menos de 50 usuários e um file server simples, a migração é factível com o time interno usando o SPMT. Vai dar trabalho, mas é viável.

Acima disso, especialmente quando há requisitos de governança, retenção regulatória, múltiplos sites ou integração com outros sistemas, ter um parceiro experiente muda o jogo. Não porque o time interno não é capaz, mas porque já viu o filme antes e sabe onde estão as armadilhas. (Aquela história do caminho de 400 caracteres, do arquivo .mdb que ninguém sabia que existia, do link de compartilhamento externo que expôs uma pasta inteira por acidente.)

A Omega Brasil conduz a migração do seu servidor de arquivos para o Microsoft 365 para empresas com governança, incluindo desenho de estrutura, classificação de dados, configuração de retenção e suporte pós-migração. Se o seu file server já deu o que tinha que dar, fale com um especialista em TI e comece o planejamento antes que a próxima auditoria pergunte onde estão os contratos de 2019.