从其他 CMS 迁移到 Daiying CMS：旧站迁移完整流程

这篇教程适合谁

如果你已经有 WordPress、Z-BlogPHP、Typecho、Emlog、Halo 或自研 CMS 站点，并希望把文章、分类、标签、页面和媒体资料逐步迁移到 Daiying CMS，可以从后台的旧站迁移入口开始。迁移不是简单复制数据库，而是先识别来源、扫描数据、试运行，再正式写入。

进入旧站迁移

支持的来源和文件

当前旧站迁移界面面向常见博客和 CMS 来源，已验证的用户可见来源包括 Z-BlogPHP、WordPress、Typecho、Emlog 和 Halo。上传文件可以是 .sql、.json、.xml 或 .zip；如果是 Daiying Migration Package V1，也可以作为标准迁移包导入。

自研 CMS 不应直接假设“任意格式都能自动迁移”。如果原系统导出的字段结构不在支持范围内，建议先由管理员或开发者整理成 Daiying CMS 可识别的 JSON、XML、SQL 或迁移包格式，再进入后台扫描。

迁移前准备

在原站导出文章、页面、分类、标签、媒体文件和必要的 URL 信息。
在 Daiying CMS 创建恢复点或保留数据库备份，避免正式迁移后难以回退。
记录原站域名、文章路径规则和重要页面 URL，后续用于 URL Mapping。
先选择少量样本数据测试，不要第一次就把全部历史数据直接写入生产。

上传并扫描

在 /admin/migrations 上传迁移文件后，系统会尝试自动检测来源和文件结构。扫描阶段不会直接替换正式内容，重点是确认可导入的内容数量、字段映射和潜在异常。

扫描结果中如果出现 skip、update 或 duplicate 等策略含义，需要先确认再执行：skip 表示跳过已有或不适合导入的项目，update 表示更新已有内容，duplicate 表示可能存在重复内容，需要人工判断是否保留。

先试运行，再执行迁移

正式迁移前建议先点击“试运行”。试运行用于验证导入计划和错误列表，适合发现分类缺失、图片地址异常、重复文章或字段不匹配等问题。确认计划无明显问题后，再执行迁移。

执行迁移时不要关闭页面或中断服务。迁移过程中如果出现失败项，可以根据后台提示继续、重试失败项，或在必要时回滚。回滚用于撤销本次迁移造成的变更，但仍建议在迁移前准备独立备份。

URL Mapping 怎么理解

URL Mapping 用来记录旧站 URL 与 Daiying CMS 新 URL 的对应关系。它的目的不是改变文章主题，而是帮助旧链接、搜索引擎收录和外部引用逐步过渡到新站。迁移后应抽查旧文章链接，确认是否能跳转到正确的新文章或页面。

图片和附件迁移限制

图片迁移通常比正文更容易出问题。远程图片可能受原站防盗链、过期链接、路径变化或网络限制影响。迁移完成后需要打开前台文章逐篇抽查封面、正文图片和附件下载，确认图片已经可访问，必要时再单独做图片本地化处理。

WordPress 评论不要过度承诺

WordPress 文章和页面可以进入迁移流程，但评论迁移不能在没有验证的情况下描述为稳定完成能力。如果原站评论很重要，应把评论作为单独项目抽样验证，确认字段、用户关系和前台展示都符合预期后再扩大迁移范围。

迁移后检查清单

前台打开新文章，检查标题、正文、图片、分类、标签和发布时间。
后台检查内容列表，确认状态不是草稿或异常状态。
检查 sitemap.xml 是否包含应被索引的新内容。
抽查旧 URL 到新 URL 的映射，避免重要链接丢失。
保留迁移日志，方便后续定位失败项或重复内容。