Atualizar vs Migrar

Bom, as duas vertentes representa finalidades em comum. No entanto um processo de migração é mais custoso, pois são várias questões a serem vistas e testadas... para garantir a mesma funcionalidade,disponibilidade e confiabilidade.
No entanto quando atualizamos uma determinada ferramenta, também é preciso tomar cuidado com as mudanças que elas nos trazem , uma grande vantagem seriam as novidades em que você poderia automatizar várias tarefas.

Tiago, infelizmente não existe a "bala de prata" para tudo...

obrigado por responder...

e mais uma coisa...aonde posso encontrar material sobre isso???

e mais uma coisa...aonde posso encontrar material sobre isso???

alguem pode ajudar a Mariana???

Mariana, na realidade não existe um material específico para isso.
O que existe são boas práticas para se realizar tal procedimento.
Particularmente, faço a instalação em um outro ambiente e deixo a contenção (para qualquer problema). O Ambiente novo passará ser utilizado após testes, pois, não será simplesmente instalar um novo servidor ou desinstalar a versão anterior do SQL e instalar a nova. Para isso, teremos que ter um ambiente de Homologação e garantir que nosso ambiente funcione sem problemas com as novas funcionalidades da versão atual do SQL. Após testes feitos e com a garantia de que o ambiente funcione, sendo que o mesmo estará em 24 x 7, se planeja a troca (porém, deixando o ambiente antigo como contenção).
Este é o melhor mundo, onde, seu cliente deve sempre estar ciente de todos os passos.

Porém, nem tudo são flores.

Você não tem o ambiente de um novo servidor para realizar este procedimento (tudo será feito no mesmo servidor) e seu cliente, ainda tem uma mentalidade pequena em relação a tecnologia (só quer receita de valores sem se importar com o bom investimento) e você, tem que virar a chave e manter o ambiente dele funcionando como se nada estivesse acontecido.
O que aconselho: garanta que a estrutura dos dados realmente esteja funcionando. Garanta o backup da base.

Após passos simples como forem tomados, faça a troca (em um período que não impacte seu cliente), tendo garantido que o mesmo irá sim funcionar antes mesmo de sua conversão. Nestes casos, testes, testes e mais testes serão muito bem aceitos.

Boa sorte.

Mariana bom dia.

Tudo parte de processo e boas praticas, agora o que é melhor ou não vai depender de como vai ser feito.
Eu particularmente sempre gosto de fazer a atualização da ferramenta, saber o que tem de novo para verificar aonde vai ser o impacto. Mais para isso existe processos a serem feitos.
Primeiro antes de aplicar as alterações e funcionalidades tem que ser testado anteriormente e bastante mesmo.
Uma dica seria Como nosso amigo acima falou, criar um ambiente novo com a nova ferramenta e fazer a instalação e futuros testes, através dessa disso você será capaz de verificar a estabilidade e posteriormente colocar em produção esse novo ambiente.
Uma colocação importante que nosso amigo acima falou foi do cliente, pois todos os clientes que nós temos hoje em dia visa em ter lucro e não importa muito com a tecnologia. O ideal é fazer o levantamento, orientar o seu cliente sobre o procedimento.
Mais o que é de suma importancia é que tem que verificar o que foi alterado na nova ferramente e caso queira migrar estudar a ferramenta para verificar se a mesma atenderá a solicitação.

Eu participei de um processo de migração, foi um caso diferente pois era migrar do MS Access para o SQL Server

Realmente, atualizar em uma visão superficial é um processo menos custoso, pois "em tese" você faz um backup para o caso das coisas darem errado, é uma solução meio deselegante, mas é mais praticada do que se imagina.

Eu gosto do caminho do ambiente limpo, ou seja, eu prefiro uma migração, ou seja, faz um servidor novo, configura o cara, e migra.

Da experiência que tive você terá dois grandes problemas.

Tipos de Campo
Procedures, Functions etc

Quanto mais distantes as versões que você vai utilizar, maior a chance de incompatibilidades.

Contudo, não para onde correr, na minha humilde e limitada visão, o trabalho é basicamente igual nos dois casos, e o ambiente fica melhor no caso da migração.

Espero ter adicionado algo a conversa

CRISTIANO JOAQUIM DOS SANTOS, obrigado pelas informações...então antes de mais nada...faça o backup de tudo que for importante, rsrsrs

DANIEL LUIZ DE MELLO COSTA, foi muito complicado fazer isso???

Alisson Obrigada pela informação.

Olá Mariana, boa tarde!!!

Eu venho acompanhando este post desde o inicio sem nunca me ter “atrevido” a comentar algo, ate mesmo pq não consegui colocar as ideias em ordem com relação ao que já “experimentei” no que se refere a esta situação, no caso não tinha uma opinião muito bem formada, no entanto lendo os posts e relembrando os casos acontecidos comigo encontrei algumas situações que são especialmente particulares, no que se resume eh que os testes são imprescindíveis, tanto para migrar quanto para atualizar.

Embora eu prefira migrar, acredito que já nas atualização corremos maiores riscos de problemas, a migração acaba nos forcando a tomar mais precauções e fazer mais testes e revisar processos e procedimentos.

Já participei de migração de versão de sistemas de ERP que utilizavam estruturas bem diferentes, participei de migrações de ERP onde tinha-se que converter todo o banco de dados e automaticamente migrar as regras de negócios e estruturação de tabelas, migração de tabelas DBF para outras tabelas DBF e de tabelas DBF para banco de dados relacionais, no caso Firebird, e de Firebird para SQL Server, migração de servidores SQL para SQL que no caso foi mais simples pq era o mesmo banco a mesma versão, foi praticamente so um backup e um restore e refazer os Jobs e algumas outras particularidades da manutenção do servidor.

O ideal seria um ambiente em produção e um ambiente pre-migracao onde poderia simular tudo que fosse necessário para a migração, após os testes feitos e chegar ao ponto de consistência desejada ai sim mudar os ambientes, o produção deixar de o ser e o pre-migracao passa-se a ser de produção.

Manter esses servidores ou se possível parte da estrutura anterior em funcionamento paralelo, desde que não interfira nem que corra o risco de algum vir a utiliza-la por engano, por algum tempo ate que tudo seja validade e que se sinta a segurança de desativa-la.

No meu caso tenho servidores ate hoje com o sistema e os copias dos bancos de dados aqui na empresa de migrações e conversões que foram feitas a bastante tempo, alguns anos rsrsr.

Como foi dito em algum dos comentários a instalação limpa, acho que seria interessante também e acaba sendo melhor.

Mas o que vai acontecer mesmo que será extremamente necessário eh perder um bom tempo, ou no caso investir um bom tempo planejando a migração, estabelecendo os processos que serão adotados e fazer inúmeros testes de conversão e de funcionamento.

Não sei se fui redundante dentro de tudo que foi falado mas gostei do post e do vem acontecendo e achei legal passar aquilo que já me deparei.

Espero também ter podido contribuir positivamente com a questão.

Abraço.

Alex - Lekao

obrigada por participar com sua opnião Alex - Lekao, nesse caso o que vale são as experiencias...alem da teoria...
imagino como é bastante complicado fazer isso, isso depende muito do ambiente.

sim, o ambiente acredito ser tbm determinante no processo.

e as experiências que vao sendo adquiridas durante os eventos de migração e/ou atualização vao determinando qual o caminho seguir.

se não me engano vc havia comentado logo no começo dos posts que não há uma bala de prata, e realmente não há.

como disse eu prefiro migrar, pq assim vou me condicionar a fazer as verificações mais minuciosas e chegar as questões de procedures, functions, etc, acredito que já mencionaram isso tbm... rsrsr

no meu caso eu prefiro migrar do que atualizar.

Abraco.

Alex - Lekao