将现有网站迁移到DNN是否繁琐？从头开始是一个更好的主意吗？
答案 0 :(得分：2)
我去年迁移了一个150页的网站，这并不乏味。
我们与DNN坐下来，计划好我们想要的结构并建立菜单--1小时 然后我们打开记事本，花了三天时间复制和粘贴。从Live Site复制，粘贴到记事本，然后按CTRL + A和CTRL + C，轻拂到DNN并再次粘贴。我的同事稍后留下的任何复杂或尴尬的页面。三天后，我们迁移了整个网站。没有工具，没有花哨的进出口。
所有这些都在几天内完成。当然，到最后，我的同事也开始加速DNN。
这是一种低技术，非常成功和简单的方法。
我会考虑高度结构化数据的导入例程，但除此之外，我推荐这种方法。
答案 1 :(得分：0)
您基本上需要重新创建网站，是的，这将是乏味的。一旦你有了一些结构，你需要重新创建页面，假设它们是简单的内容页面。
但是，如果您有一个典型的数据驱动的.NET应用程序，它具有大量服务器端代码和数据访问权限，那么您将不得不重新设计其中许多内容以适应DNN。
无论如何，如果要维护现有的用户列表，您可能必须编写新的DNN成员资格提供程序以与该列表进行交互。如果您已经使用了默认的ASP.NET成员资格表，那么这基本上应该为您完成，因为这是DNN默认在内部使用的内容，尽管它确实用它自己的成员资格提供程序interace包装它，因为它们的用户必须假装是特定于门户的（即使它们确实不是）。
希望您的许多代码都在用户控件和类中。如果是这样，您可以将它们包装在DNN容器中。这将是乏味的，需要修复很多错误，但它是可行的。
如果您的代码是在一堆页面中散布的一堆spagetti，您可能需要进行大量更改才能将它们放入DNN容器中。
您必须决定如何处理现有数据库。你会将它合并到DNN数据库中，还是将它保持独立。单独的想法很好，因为它使DNN表示垃圾远离您的核心功能，但请记住您的用户/角色/权限也将在DNN数据库中，因此您可能会丢失与旧数据的链接。
这会导致角色和权限。 DNN使用标准的ASP.NET角色提供程序接口，但实际上并不那么简单。即使您提供自己的角色提供程序以与您自己的角色集成，您仍然需要将角色和用户/角色分配持久保存到DNN表，因为它不是完全抽象的。
......我确信还有一些我认为不适合你的情况的其他事情。
无论如何，你可能会在中间的某个地方结束。您将找不到一些神奇的迁移实用程序，可以直接移植您的东西，但您可能不必重写每行代码。根据您网站的规模和复杂程度，您可能需要使用具有DNN专业知识的人员进行大量分析，以找出可靠的计划。