Conseils pour la migration des applications MS Access vers les applications .Net

Question

Je vais bientôt entamer le douloureux*(je plaisante)* processus de migration de plusieurs applications Access distinctes vers de "vraies" applications*(remarquez les guillemets, pas de guerre des nerfs s'il vous plaît)*. Il s'agira très probablement d'applications Web, car la raison habituelle est la multiplicité des utilisateurs et la facilité de déploiement, mais je prendrai les choses au cas par cas.

Certaines de ces applications sont des applications Access traditionnelles utilisant Access comme back-end et d'autres utilisent SQL Server (un serveur central) comme back-end.

Ce que je recherche, c'est une combinaison de votre expérience en la matière et des ressources que vous avez utilisées pour vous aider.

Sites web, applications, normes, meilleures pratiques, "gotcha's", "don't forget", etc.

Je suis un atelier C# d'une seule personne avec un back-end SQL Server, donc que ce soit Web ou non, je regarderai dans cette direction.

Par ailleurs, est-il exagéré ou irréalisable d'essayer de développer un cadre pour ce genre de choses ? Y aurait-il simplement TROP de variables pour même essayer de suivre cette voie ? Quelqu'un a déjà essayé ?

---

Quelques informations supplémentaires basées sur les questions ci-dessous. Nous avons actuellement ~250 utilisateurs et ils sont répartis sur 5 sites.

Ce que j'entendais par "déployabilité" est peut-être un peu vague. Je voulais simplement dire que nous sommes une organisation à but non lucratif et qu'en tant que telle, nous ne disposons pas de la meilleure bande passante possible. Le déploiement d'applications complètes, même par le biais de ClickOnce, peut s'avérer délicat lorsqu'il est combiné à la nature très inconstante de mes utilisateurs* (je veux cette boîte violette, pas verte, pas du tout du genre à m'en débarrasser...)*.

Mon idée est d'essayer de développer un "cadre", en quelque sorte, qui aidera à rationaliser le processus de passage d'une application Access à une application .Net.

Maintenant, je comprends parfaitement que ce "cadre" peut n'être rien de plus qu'un ensemble d'étapes et de lignes directrices ; par exemple, utiliser un ORM*(LINQ2SQL ou SubSonic)* pour générer le DAL, copier l'interface utilisateur dans les contrôles d'utilisateur correspondants, réécrire la logique d'entreprise.

Je cherche simplement votre expérience/expertise pour m'aider à rationaliser mon processus de rationalisation... ;)

Answer 1

Les applications qui utilisent une base de données Access pour stocker les tableaux et qui ont besoin d'un accès Web doivent d'abord être mises à niveau vers SQL Server. Il existe un outil du groupe SQL Server. SQL Server Migration Assistant for Access (SSMA Access)

Envisagez ensuite de déplacer sur le Web uniquement la partie de l'application qui nécessite un accès à distance. Et laisser le reste de l'application dans Access. Cela pourrait vous faire gagner un temps considérable.

Vous pouvez également envisager de passer à Terminal Server. Avec un VPN, vous n'aurez à débourser que quelques frais de licences logicielles et vous n'aurez pratiquement rien à faire.

Cela dit, qu'entendez-vous par "utilisateurs multiples" et "déployabilité" ? Nous pourrons peut-être vous donner quelques suggestions à ce sujet. Access est multi-utilisateurs dès sa sortie de l'emballage. Cependant, si vous avez des données critiques, si vous ne pouvez pas recoder les données en cas de corruption ou si vous avez plus de 25-50 utilisateurs sur le réseau local, vous devriez déplacer les données vers SQL Server.

Maintenant qu'il est public, Access 2010 peut déployer des applications sur le Web. Toutes sortes de choses très intéressantes peuvent être faites. Pour plus d'informations, consultez le site Blog du groupe de produits Microsoft Access ou mon blog avec les balises Access 2010 appropriées

Answer 2

D'après mon expérience, je pense que vous devez procéder à une mise à niveau au cas par cas. La mise à niveau est essentiellement une réécriture à partir de zéro et vous devriez profiter de l'occasion pour revoir la conception si nécessaire. Le type de structure d'application et le style de code utilisés pour Access (probablement procédural, je suppose) sont très différents d'une application OO .Net bien conçue.

Vous pourrez réutiliser les bases de données SQL Server bien sûr et, selon les applications, peut-être même celles d'Access. Si vous vous sentez courageux, vous pouvez même essayer l'assistant de redimensionnement, bien que je ne le recommande pas, car les résultats sont loin d'être idéaux.

Je vous conseille également de jeter un coup d'œil à une sorte d'outil ORM (nous utilisons Subsonic) car cela peut réduire considérablement la quantité de code passe-partout que vous devez écrire. Certains outils ORM peuvent également générer des DDL pour votre base de données.

Nous suivons ces (il est bon de choisir une norme dès le début et de s'y tenir, comme nous l'avons constaté). ce vraiment utile pour être opérationnel.

J'espère que cela vous a aidé.