SQL Server 2016 perde suporte em julho de 2026: rota de saída

📚 Continue aprendendo sobre este tema:

O que muda em 14 de julho de 2026

Nada apaga e nada trava. Na segunda-feira seguinte o banco sobe igual, as consultas respondem igual e os usuários não percebem diferença nenhuma. O que acaba é o fluxo de correções de segurança que o fabricante publica quando uma falha nova é descoberta.

Traduzindo para linguagem de risco: a partir dali, cada vulnerabilidade divulgada continua valendo para a sua instância e não chega correção. O banco vira um alvo que envelhece sozinho. Como o banco costuma guardar exatamente o que a empresa tem de mais sensível, cadastro de cliente, financeiro, pedido e histórico, ele não é um item qualquer do parque.

Há também o lado contratual. Auditoria, seguro cibernético, cliente grande e edital costumam perguntar se os sistemas estão em versão suportada. Rodar banco fora de suporte sem plano documentado é um item difícil de justificar por escrito.

Duas datas para guardar

14/07/2026: fim do suporte estendido do SQL Server 2016.
17/07/2029: limite de disponibilidade do ESU, o Extended Security Updates, que entrega apenas atualizações de segurança para quem contrata.

Repare que o ESU não é solução, é prorrogação com data marcada. Ele existe para dar fôlego a quem precisa de tempo, não para substituir a modernização.

Como saber se a sua empresa ainda tem SQL Server 2016 rodando

Muita média empresa responde que não tem e descobre depois que tem. O banco costuma estar escondido dentro de um sistema que foi comprado pronto, e o cliente nunca soube qual banco veio junto. Alguns lugares onde ele aparece com frequência:

Sistemas comerciais instalados no servidor da empresa, com banco embutido no pacote de instalação.
Servidor de aplicação antigo que ninguém mexe porque está funcionando.
Instâncias de edições gratuitas usadas por alguma área para um controle paralelo.
Servidor de teste que virou produção com o tempo e nunca foi tratado como tal.
Máquina virtual esquecida no ambiente, ligada e sem dono definido.

Uma varredura simples da rede resolve a dúvida em pouco tempo e evita a pior das situações, que é descobrir a instância só quando alguém a explora.

As quatro rotas, comparadas

Rota	Quando faz sentido	Principal risco	Esforço
Atualizar a instância no lugar	Servidor recente, base pequena, aplicação simples e homologada	Se der errado, o caminho de volta é restaurar, e isso leva tempo	Menor
Migrar para servidor novo com versão atual	Hardware velho, sistema operacional também vencendo, base grande	Precisa de janela de corte e de sincronização de dados	Médio
Mover para serviço gerenciado, como o Azure SQL	Vontade de sair da manutenção de servidor e de patch de banco	Recursos e comportamentos que a aplicação usa podem não existir igual	Maior
Contratar ESU e ganhar tempo	Aplicação sem homologação para versão nova ou fornecedor sem prazo	Custo recorrente e adiamento do problema, com prazo final em 2029	Menor no curto prazo

Uma observação importante: essas rotas não são excludentes. É comum uma empresa atualizar em julho os bancos simples, contratar ESU para a única base presa a um sistema legado e planejar a ida para nuvem no ano seguinte, com calma.

Como escolher, na prática

A decisão sai de cinco perguntas, e nenhuma delas é sobre o banco:

O fornecedor da aplicação homologa a versão nova do SQL Server? Se não homologa, a rota de atualização direta está fechada até ele se posicionar.
Quem sustenta a aplicação hoje? Sistema desenvolvido internamente por alguém que saiu da empresa muda completamente o tamanho do risco.
Qual é o tamanho da base e quanto tempo leva o restore? Isso define a janela e o plano de volta.
O sistema operacional do servidor também está perto do fim? Se o Windows Server abaixo também vence, faz sentido resolver os dois de uma vez em vez de parar a operação duas vezes.
Existe integração antiga apontando para esse banco? Relatório em Excel, robô de conciliação, BI e sistema de terceiro costumam usar driver e conexão antigos.

Se o servidor abaixo do banco também estiver em contagem regressiva, vale ler o plano descrito em Windows Server 2016 acaba em janeiro de 2027 e juntar os dois projetos numa janela só.

O que costuma quebrar

Migração de banco raramente falha por causa do banco. Falha pelo que está pendurado nele. A lista abaixo cobre a maior parte dos sustos:

Nível de compatibilidade. A base pode subir na versão nova mantendo o comportamento antigo. Isso salva a virada, mas precisa ser decidido conscientemente, não por acidente.
Consultas que mudam de plano. Um relatório que rodava em segundos pode ficar lento depois da atualização. É o problema mais comum e o mais fácil de tratar quando foi medido antes.
Jobs e rotinas agendadas. Backup, expurgo, integração noturna e envio de relatório. Ninguém lembra deles até pararem.
Servidores vinculados e pacotes de integração. Conexões entre bancos e fluxos de carga guardam credencial e caminho fixos.
Drivers antigos na aplicação. Conexão legada às vezes não fala com configuração de segurança mais moderna.
Usuários órfãos. Depois de restaurar em outro servidor, logins e usuários da base podem se desencontrar.
Collation. Diferença de ordenação e acentuação entre servidores gera erro sutil, do tipo que só aparece num relatório específico.
Recursos de edição. Nem tudo que existe numa edição existe na outra. Vale conferir antes de escolher a licença.

Roteiro de saída

1. Inventário do que existe

Liste todas as instâncias, versões, edições, bases, tamanho de cada base, aplicações que consomem cada uma e o responsável de negócio. Sem esse mapa você não consegue nem estimar esforço. O método está em inventário de TI: o primeiro passo que quase toda empresa pula.

2. Linha de base de desempenho

Antes de mexer, meça. Tempo das consultas mais usadas, duração das rotinas noturnas, uso de CPU, memória e disco nos horários de pico. Sem linha de base, qualquer reclamação depois da virada vira discussão sem prova. As métricas que valem a pena acompanhar estão em como monitorar servidores e as métricas que importam.

3. Conversa com os fornecedores

Pergunte por escrito qual versão do SQL Server cada sistema homologa hoje. Resposta verbal não serve, porque é justamente essa resposta que define a rota e o cronograma.

4. Teste em ambiente separado

Restaure uma cópia recente da base num ambiente isolado e execute lá a rota escolhida. É onde você mede o tempo real da atualização, descobre o que quebra e ensaia o plano de volta. O tempo medido no teste é o que você leva para a negociação da janela.

5. Janela e plano de volta

Defina data fora do fechamento, duração declarada, ponto de não retorno e o passo a passo do rollback. Backup completo e restaurado em outro lugar antes de começar. Backup que nunca foi restaurado é promessa, não garantia.

6. Estabilização

Na primeira semana depois da virada, monitoramento reforçado e comparação com a linha de base. Consulta que ficou mais lenta se resolve rápido quando é detectada rápido.

Quanto tempo isso leva

Não existe número universal, e desconfie de quem der um. O que existe é uma ordem de grandeza previsível: o levantamento e a conversa com fornecedores costumam consumir mais calendário que a atualização em si, porque dependem de terceiros. A execução técnica de uma instância simples cabe numa madrugada. O que estica o projeto é aplicação sem homologação, base gigante sem janela e integração antiga sem dono.

Por isso, quem começa o levantamento agora tem margem para escolher a rota. Quem começa em julho vai ficar com a única rota que não depende de ninguém, que é pagar por mais tempo.

Perguntas frequentes

O SQL Server 2016 para de funcionar em 14/07/2026?

Não. Ele continua rodando normalmente e nenhuma função é desligada. O que termina é o fornecimento de correções de segurança sem custo adicional. Na prática, cada nova vulnerabilidade descoberta depois dessa data continua valendo para a sua instância sem correção disponível, o que aumenta o risco de forma contínua e transfere a exposição para quem guarda os dados.

Vale a pena comprar o ESU em vez de migrar?

Vale quando existe um motivo concreto, como uma aplicação crítica que ainda não homologa versão nova ou um projeto grande já em andamento que não pode ser interrompido. O ESU entrega apenas atualizações de segurança e está disponível até 17/07/2029, então ele compra tempo com data marcada. Comprar ESU sem um plano de saída escrito significa pagar duas vezes: pelo prazo extra agora e pela migração depois, provavelmente com mais pressa.

Migrar para Azure SQL resolve o problema de uma vez?

Resolve a parte de manter versão e correções em dia, porque a plataforma cuida disso. Em compensação, é a rota que exige mais análise antes, já que a aplicação pode depender de recursos e comportamentos que funcionam de forma diferente num serviço gerenciado. O caminho seguro é testar a base numa cópia antes de decidir e avaliar também rede, latência e custo recorrente, na mesma lógica de qualquer projeto de nuvem descrita em migrar para a nuvem: por onde começar.

Onde a BS IT Solutions entra

A BS IT Solutions faz o levantamento das instâncias, mede a linha de base de desempenho, testa a rota escolhida em ambiente separado, executa a janela com plano de volta e acompanha a estabilização com NOC 24x7. Atendemos médias empresas e PMEs em São Paulo e região metropolitana de forma presencial, e remotamente no Brasil inteiro.

Se você ainda não sabe quantas instâncias de SQL Server 2016 existem na sua empresa nem quais sistemas dependem delas, esse é o primeiro trabalho e ele precisa começar antes de julho. Conheça o serviço de gestão de servidores e fale com um especialista da BS IT Solutions para desenhar a rota de saída do seu ambiente.