Você tem SQL Server 2012 rodando em produção.
Sim. 2012. Lançado há 12 anos.
Porque funciona. Porque ninguém quer mexer. Porque “se não tá quebrado, não mexe”.
Mas aqui está o problema: SQL 2012 não tem mais suporte da Microsoft. Patches de segurança? Não. Bugfix? Não. Você está rodando um sistema que a Microsoft oficialmente abandonou.
Pior: dados armazenados em SQL 2012 são antigos. Não é só sobre tecnologia obsoleta. É sobre dados presos em formato desatualizado.
Você precisa atualizar. Mas como, sem quebrar tudo?
Verificação 1: Em Qual Versão Você Está?
Primeira coisa: você sabe qual versão está rodando?
Execute isso em SQL:
SELECT @@VERSION
Se disser “2012”, “2008”, “2005”… você está em perigo. Se disser “2016” ou “2019”… você está ok mas perto do fim.
Se disser “2022”… você está moderno.
Respondeu qual? Se for anterior a 2016, continue lendo.
Verificação 2: Qual É Seu Tamanho de Dados?
Banco de dados pequeno (< 10 GB): Atualização é fácil. Um fim de semana, downtime de 4 horas.
Banco de dados médio (10-100 GB): Precisa planejamento. Talvez uptime parcial durante migração.
Banco de dados grande (> 100 GB): Precisa arquitetura completa. Always On, replicação, failover automático.
Você sabe qual é seu tamanho?
exec sp_spaceused
Verificação 3: Qual É Seu SLA (Service Level Agreement)?
Você pode ficar offline 1 dia? 1 hora? 30 minutos? Zero minutos?
Se pode ficar offline, atualização é simples.
Se não pode (aplicação critical), precisa de Always On ou replicação (mais complexo).
Verificação 4: Qual É Seu Conhecimento Técnico?
Você tem DBA em casa que mexe com SQL? Ou SQL é “aquele banco de dados que funciona”?
Se tem expertise, pode fazer parte do upgrade sozinho.
Se não tem, precisa trazer consultor.
Os 4 Caminhos Para Atualizar
CAMINHO 1: In-Place Upgrade (Mais Arriscado)
Você atualiza a versão no servidor atual. Downtime: 2-4 horas. Risco: se der problema, você está sem rollback.
Só recomendado para: Dados < 10 GB, SLA pode ter 4h de downtime, você conhece SQL bem.
CAMINHO 2: Backup & Restore em Servidor Novo (Mais Seguro)
Você cria um servidor novo com SQL 2019 ou 2022. Faz backup do banco antigo, restaura no novo. Aponta aplicação para novo server.
Downtime: 30 minutos a 2 horas (depende tamanho). Rollback: fácil, volta pra old server.
Recomendado para: Maioria das empresas. Dados até 100 GB. SLA de 2 horas é aceitável.
CAMINHO 3: Always On (Zero Downtime)
Você configura Always On: sincroniza dados em tempo real entre servidor antigo e novo. Quando new está 100% sincronizado, você faz failover.
Downtime: ~30 segundos (o tempo de failover). Aplicação reconecta automaticamente.
Recomendado para: Aplicações críticas. Dados > 50 GB. SLA zero downtime.
Complexidade: Alta. Precisa arquitetura. Precisa DBA.
CAMINHO 4: Replicação Transacional (Meio Termo)
Você configura replicação transacional: toda mudança no banco antigo é replicada pro novo em segundos.
Quando estiver sincronizado, você para aplicação (1-2 minutos downtime), faz última sincronização, e aponta pro novo.
Downtime: 2-5 minutos. Rollback: possível mas meio complicado.
Recomendado para: Dados 100-500 GB. SLA de 5 minutos é aceitável.
O Timeline Ideal
Semana 1: Planejamento
Você descobre (com ajuda se precisar): tamanho, SLA, arquitetura atual, qual caminho tomar.
Semana 2-3: Preparação
Se usando Always On ou Replicação: setup do novo servidor, configuração de sync.
Semana 4: Testes
Você faz um teste de failover (sem afetar produção) para garantir que funciona.
Semana 5: Execução
Final de semana, fora do horário de pico, você faz o upgrade/failover.
Semana 6: Monitoramento
Você fica atentando pro novo servidor os próximos dias pra garantir que tudo funciona.
Total: 6 semanas do planejamento ao novo servidor rodando.
Os Riscos de NÃO Atualizar
• Segurança: SQL 2012 não recebe patches. Uma vulnerabilidade descoberta amanhã nunca vai ser patched.
• Performance: SQL 2022 é 50-200% mais rápido que SQL 2012. Você está deixando velocidade na mesa.
• Compatibilidade: Novas aplicações cada vez menos suportam SQL antigo. Você vai ficar preso na versão que tem.
• Compliance: Você pode estar violando LGPD ou outras regulações rodando software sem suporte.
• Custo total de propriedade: SQL antigo exige DBA mais experiente (caro). SQL novo é mais automatizado.
*(Estimativas baseadas em estudos de migração)*
Implementar upgrade: R$ 30-50 mil (depende caminho e tamanho)
Custo de breach por SQL desatualizado: R$ 500 mil+
Perda de performance anual (deixando dados em SQL antigo): R$ 50-100 mil em produtividade
A Solved TI Faz Isso Direito
A Solved já migrou dezenas de empresas de SQL antigo pra novo. Sabe:
• Qual caminho é melhor pra seu tamanho/SLA
• Como fazer com zero (ou mínimo) downtime
• Como testar antes de “ir pro real”
• Como fazer rollback se der problema
Quer um workshop de 1 dia pra avaliar sua situação? Custa R$ 5 mil. Você descobre: qual é seu banco, qual é o risco, qual é o caminho ideal, quanto demora, quanto custa.
Com esses dados em mão, você toma decisão informada.
Conclusão: Sua Cápsula do Tempo Precisa de Upgrade
SQL 2012 funcionou bem. Por 12 anos. Mas o tempo é implacável. Tecnologia passa. Segurança evolui. Você precisa acompanhar.
O bom é que atualizar é bem mais fácil de fazer hoje do que era há 5 anos. Always On, replicação transacional, backup/restore moderno… você tem opções que funcionam.
O ruim é que quanto mais você demora, mais complicado fica. SQL 2005 pra SQL 2022 é salto enorme. SQL 2019 pra 2022 é fácil.
Não deixe pro próximo ano. Faça agora.
