Impact sur l'application lors de la migration de sql server 2005 à 2008

C'est une question très large bien sûr, mais je vais essayer de donner quelques suggestions sur la façon dont je l'aborderais :

1. Le premier objectif est d'écrire des scripts (procédures stockées) qui testent votre base de données 2005. Exécutez tous vos sprocs existants, comptez les enregistrements dans les tables, répertoriez les index, etc. Vous faites cela pour pouvoir les exécuter en 2005 puis en 2008/2012 une fois la migration terminée. Cela vous aidera à prouver le schéma et les données ont réussi.

2. Faites une sauvegarde de la base de données 2005 et restaurez-la en 2008/2012. Vous pouvez le faire en parallèle à l'étape 1 si vous le souhaitez. Commencez simplement à l'utiliser. Est-ce que tout s'est bien importé ? Passe-t-il le test de la vue ? Des erreurs à corriger ?

3. Après l'étape 2, continuez et faites une copie de votre code .NET 2.0 actuel et pointez-le vers la nouvelle instance de l'étape 2. L'application fonctionne-t-elle ? Encore une fois, passe-t-il le test de la vue ?

4. Itérez avec la copie de l'application et la nouvelle base de données jusqu'à ce que vous vous sentiez en confiance. Si vous avez une suite de tests pour votre base de code, cela vous aidera évidemment à prouver que tout va bien plutôt que d'utiliser votre intuition.

Quant à passer de .NET 2.0 à .NET 4.0/4.5...

1. La base de code doit être rétrocompatible. Le seul problème que j'ai pu voir est si d'autres systèmes dépendent de votre base de code. Si vous avez une bibliothèque principale et que vous souhaitez la mettre à niveau vers la version 4.0 - et qu'un autre système qui est toujours sur la version 2.0 a besoin de cette bibliothèque, alors vous avez des problèmes.

2. J'attendrais certainement de mettre à jour la version .NET jusqu'à après vous terminez la migration de la base de données. Si les choses tournent mal lors de la migration, vous voulez savoir qu'il ne s'agit pas de .NET. Cela vous aidera à réduire les bogues et les problèmes.

Après avoir effectué de nombreuses migrations comme celle-ci, quelques conseils généraux :

1. N'hésitez pas à créer de nouvelles instances/systèmes et tester, tester, tester. N'essayez pas de travailler directement avec du code existant dans le contrôle de code source ou de travailler avec des déploiements/serveurs existants. Copiez-le et testez.

2. Écrivez des outils et des scripts qui vous aident à automatiser les tests système. Vous voulez pouvoir savoir "Oui, autant que je sache, le schéma est revenu exactement de la même manière."

3. Ne faites pas vos itérations trop longues. Itérez de petites manières, puis prouvez que cela a fonctionné, puis passez à autre chose.

J'espère que ça aide.