将网站内容迁移到新 SharePoint 网站的最佳方法
我的团队正在开展一个将 .com 网站迁移到 SharePoint 的项目。
创建所有外观资产、母版页、内容类型和页面布局后，我们需要将实际网站页面“移动”到 SharePoint 中。
我正在努力想出最有效的方法来做到这一点。 我们的拓扑由创作环境和生产环境组成。 我们计划使用 SharePoint 内容部署从创作填充生产。
然而，我们显然需要对创作环境进行某种初始填充。 我不想使用内容部署从开发环境填充创作，因为我不想最初从空白站点定义创建创作。
以下是我提出的选项，希望得到一些您认为最好的方法的反馈：
在开发环境中创建网站内容并使用 SPDeploy 等工具将其迁移到创作环境中
直接在创作环境中创建内容
使用与在功能中配置列表项实例类似的技术。 我们将使用功能创建和填充所有内容
- 我不确定这是否确实可行，但我之所以有这个想法，是因为我知道在功能中配置列表时可以创建列表项实例。 毕竟，我们的页面库是页面列表 - 但是涉及多种内容类型。
谢谢你的建议！
My team is working on a project to migrate a .com site into SharePoint.
After all our look and feel assets, master pages, content types, and page layouts are created, we need to actually "move" the actual site pages into SharePoint.
I'm trying to come up with the most effective way to do this. Our topology consists of an Authoring and a Production environment. We plan to use SharePoint Content Deployment to populate Production from Authoring.
However, we obviously need to do some sort of initial population of the Authoring environment. I don't want to use Content Deployment to populate Authoring from a development environment because I don't want to initially create Authoring from a Blank Site definition.
Here are the options I came up with, would love some feedback on which you think would be the best approach:
Create the site content in a development environment and use a tool such as SPDeploy to migrate it into the Authoring environment
Create the content directly in the Authoring environment
Use a technique similar to how you can provision List Item instances in a feature. We would create and populate all of our content using Features
- I'm not sure if this is actually doable, but got the idea because of how I know you can create List Item instances when provisioning a List in a feature. After all, our Pages library is a list of Pages - however there are multiple content types involved.
Thank you for your suggestions!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果只是迁移文件的问题，您实际上可以使用内容迁移框架。 此框架的核心类是 Microsoft.SharePoint.Deployment 命名空间中的 SPExport 和 SPImport 类。 您可以使用相当少的代码将单个文件导出到磁盘，然后将它们再次导入到新位置。 或者，也可以在此处尝试 CodePlex 上的 SharePoint 内容部署向导：http://www.codeplex.com/SPDeploymentWizard。 它会节省你的编码。
If it is just a matter of migrating files, you could actually use the content migration framework. The core classes of this framework are the SPExport and SPImport classes in the Microsoft.SharePoint.Deployment namespace. You can with fairly little code export individual files to disk and import them again to a new location. Alternatively, try the SharePoint Content Deployment Wizard on CodePlex here: http://www.codeplex.com/SPDeploymentWizard. It will save you the coding.
备份和恢复内容数据库。
Backup and restore the content DB.
您能否澄清为什么您不想使用内容部署来创建初始创作网站？ 为什么您不想从空白站点定义开始？ 无论如何，它都会在部署过程中被覆盖。 stsadm -export / -import 怎么样？
抱歉，我还是不太清楚整个情况。 您有一个开发环境（大概是在其中创建结构，但不是任何用于生产的内容）、一个创作环境（我将其理解为输入和批准内容的锁定环境），然后是一个只读生产环境部署了哪些批准的项目。 如果是这种情况，那么我可以说我的一个项目有类似的设置。
就我而言，我最初在我的开发环境中开发了站点结构，然后备份并恢复到创作和生产。 随后对这两种环境的结构更改都是手工进行的。 创作在结构上几乎与产品完全相同。 只是安全性不同。 内容每天从创作到产品都会部署多次。 我们直接在创作环境中进行内容更改。
Can you clarify on why you don't want to use content deployment to create your initial Authoring site? Why do you not want to start with a blank site definition? It would get overwritten in the deployment process anyway. What about stsadm -export / -import?
I'm sorry, but I'm still not clear on the whole situation. You have a development environment (presumably where structure is created, but not any content destined for production), an authoring environment (which I understand as a locked down environment where content is entered and approved), and then a read-only production environment to which approved items are deployed. If this is the case, then I can say that I have a similar setup on one of my projects.
In my case, I initially developed the site structure in my dev environment, then backed up and restored to authoring and prod. Subsequent structural changes to both environments are made by hand. Authoring is structurally almost exactly the same as prod. Only the security is different. Several times per day content is deployed from authoring to prod. We make content changes directly in the authoring environment.