将当前网站迁移到dotnetnuke

将现有网站迁移到DNN是否繁琐？从头开始是个更好的主意吗？

我去年迁移了一个150页的网站，它并不乏味

我们和DNN坐下来，计划了我们想要的结构，并制作了菜单-1小时 然后我们打开记事本，花了三天时间复制和粘贴。从Live站点复制，粘贴到记事本，然后按CTRL+A和CTRL+C，切换到DNN并再次粘贴。我同事留下的任何复杂的或arkward的页面供以后使用。三天后，我们迁移了整个站点。没有工具，没有华丽的进出口

这一切都在几天内完成。当然，到最后，我的同事也掌握了DNN的最新进展

这是一种低技术、高度成功且简单的方法

---

我会考虑对高度结构化的数据进行导入例程，但另外，我推荐这种方法。

你基本上需要重新创建站点，是的，这将是冗长乏味的。一旦有了一些结构，就需要重新创建页面，假设它们是简单的内容页面

但是，如果您有一个典型的数据驱动的.NET应用程序，其中包含大量的服务器端代码和数据访问，那么您必须重新设计大量的应用程序以适应DNN

无论如何，如果您想维护现有的用户列表，您可能需要编写一个新的DNN成员资格提供程序来与该列表交互。如果您已经在使用默认的ASP.NET成员资格表，那么基本上应该为您这样做，因为这是DNN在默认情况下内部使用的，尽管它确实使用自己的成员资格提供程序interace来包装它，因为他们的用户必须假装是特定于门户的（即使他们确实不是）

希望您的许多代码都在用户控件和类中。如果是这样，您可能可以将它们包装在DNN容器中。这将是乏味的，需要大量的错误修复，但它是可行的

如果您的代码是一堆散开在一堆页面上的spagetti，那么您可能需要做很多更改才能将它们放入DNN容器中

您必须决定如何处理现有数据库。您是将其合并到DNN数据库中，还是将其分开。单独的想法很好，因为它使DNN演示文稿垃圾远离您的核心功能，但请记住，您的用户/角色/权限也将位于DNN数据库中，因此您可能会丢失到旧数据的链接

这将导致角色和权限。DNN使用标准的ASP.NET角色提供程序接口，但实际上并没有那么简单。即使您提供自己的角色提供程序来与自己的角色集成，您仍然需要将角色和用户/角色分配持久化到DNN表中，因为它不是完全抽象的

。。。我敢肯定还有很多其他的事情是我想不出来的

---

无论如何，你最终可能会在中间。你不会发现一些神奇的迁移工具可以直接移植你的东西，但是你可能也不需要重新编写每一行代码。根据站点的大小和复杂性，您可能需要使用一些具有DNN专业知识的人员进行大量分析，以制定一个可靠的计划

嗨，迈克，我想说的是，另一种方法，构建一个自动化工具，测试、执行和签署，包括客户，然后审查整个流程，这将需要三天以上的时间，而且人员仍然需要接受培训，站点结构仍然需要规划。当然，这很乏味，但是如果迁移站点的费用是2000欧元，您会选择哪种解决方案？