Migration du site Web actuel vers dotnetnuke

Question

Est-il fastidieux de migrer un site Web existant vers DNN? Est-ce que partir de zéro sera une meilleure idée?

Answer 1

J'ai migré un site Web de 150 pages l'année dernière et ce n'était pas fastidieux.

Nous nous sommes assis avec DNN, planifié la structure que nous voulions et construire le menu - 1 heure Ensuite, nous avons ouvert le Bloc-notes, et j'ai passé trois jours à copier et coller. Copier à partir du site en direct, coller dans le bloc-notes, et CTRL + A et CTRL + C, feuilletez vers DNN et collez à nouveau. Toutes les pages complexes ou difficiles que mon collègue a laissées pour plus tard. Après trois jours, nous avons migré l'ensemble du site. Pas d'outils, pas d'importation et d'exportation fantaisie.

Tout cela en quelques jours. Et bien sûr, à la fin de celle-ci, mon collègue était également à jour sur DNN.

C'est une approche low tech, très réussie et facile.

Je considérerais des routines d'importation pour des données hautement structurées, mais sinon, je recommande cette approche.

Answer 2

Vous aurez essentiellement besoin de recréer le site, et oui ce sera fastidieux. Une fois que la structure est en place, vous devez recréer les pages, en supposant qu'il s'agit de pages de contenu simples. Cependant, si vous disposez d'une application .NET pilotée par les données avec beaucoup de code et d'accès aux données côté serveur, vous devrez en modifier beaucoup pour les adapter à DNN. Quoiqu'il en soit, si vous souhaitez conserver votre liste d'utilisateurs existante, vous devrez probablement écrire un nouveau fournisseur d'appartenance DNN pour interagir avec cette liste. Si vous utilisiez déjà les tables d'appartenance ASP.NET par défaut, cela devrait essentiellement être fait pour vous, car c'est ce que DNN utilise par défaut en interne, bien qu'il l'enveloppe avec son propre interace de fournisseur d'appartenances, car leurs utilisateurs doivent faire semblant. être spécifique au portail (même si ce n'est pas le cas).

Espérons qu'une grande partie de votre code se trouve dans les contrôles utilisateur et les classes. Si oui, vous pouvez probablement les envelopper dans des conteneurs DNN. Ce sera fastidieux et exigera beaucoup de corrections de bugs, mais c'est faisable.

Si votre code est plutôt un groupe de spagetti étalé sur un tas de pages, vous devrez probablement faire beaucoup de changements pour les mettre dans des conteneurs DNN.

Vous devrez décider quoi faire de votre base de données existante. Allez-vous le fusionner dans la base de données DNN, ou allez-vous le garder séparé. L'idée distincte est intéressante car elle évite que les fonctionnalités de la DNN ne soient trop importantes, mais gardez à l'esprit que vos utilisateurs/rôles/permissions seront également dans la base de données DNN, vous risquez donc de perdre ce lien vers vos anciennes données.

Ce qui conduit à des rôles et des autorisations. DNN utilise l'interface de fournisseur de rôle ASP.NET standard, mais ce n'est pas si simple. Même si vous fournissez votre propre fournisseur de rôles pour l'intégrer à vos propres rôles, vous devrez toujours conserver les rôles et les affectations utilisateur/rôle aux tables DNN, car elles ne sont pas parfaitement abstraites.

... et je suis sûr qu'il y a beaucoup d'autres choses spécifiques à votre situation auxquelles je ne peux penser.

De toute façon, vous finirez probablement quelque part au milieu. Vous ne trouverez pas d'utilitaire de migration magique qui transmettra vos données directement, mais vous n'aurez probablement pas à réécrire chaque ligne de code non plus.En fonction de la taille et de la complexité de votre site, vous devrez probablement faire beaucoup d'analyses, en utilisant certaines personnes ayant l'expertise de DNN, pour trouver un plan solide.