Minimizar o tempo de migração

Você pode reduzir significativamente a quantidade de tempo de inatividade executando as versões atuais e novas em paralelo. Use algo como Log Shipping, Always On Availability Groups ou até mesmo replicação para gerar uma cópia do seu banco de dados em uma nova instância que esteja executando qualquer versão mais recente para a qual você deseja atualizar. Eu usaria o Log Shipping, pois é o mais simples, tecnicamente, e está disponível em qualquer edição do SQL Server. Always On AG deixa você mais próximo da sincronização, mas exige um pouco mais de trabalho para configurar. Repl é meio que no meio.

Pode demorar um pouco para que ambos os bancos de dados estejam "quase" sincronizados, dependendo do tamanho do banco de dados e da sua infraestrutura, mas isso não é tão importante, pois seu sistema está online o tempo todo. Depois de chegar a um estado estável em que todos os dados existentes do banco de dados original foram movidos para o novo banco de dados e você ficou com apenas novas transações para mover, interrompa as transações no original e deixe todos os dados serem movidos para o novo banco de dados. O método/comando real depende de qual abordagem você adota, mas todos estão bem documentados no MSDN.

Verifique se todas as transações pendentes foram enviadas para o novo banco de dados e faça as alterações necessárias para que os aplicativos apontem para o novo banco de dados. Por fim, execute testes de validação no novo banco de dados para garantir que tudo funcione como deveria (mesmo que você tenha testado em seu ambiente de pré-produção/QA) e reative aplicativos/transações se tudo estiver limpo.

Isso coloca a maior parte do seu tempo de inatividade em quaisquer testes que você precise executar e você realmente não deve pular essa parte. Mudar de Log Shipping, AlwaysOn AG ou replicação é uma questão de minutos, desde que não haja gargalos de servidor, armazenamento ou rede.