换 CMS 的理由很多：原系统太慢、插件不再维护、需要多语言、老板想换。但迁移做不好，等于把几年积累的收录和排名一次性清零。
一、迁移前必须搞清楚的三件事
- 内容量。多少文章、多少产品、多少图片。这决定迁移方式（脚本还是手工）。
- URL 规则。新旧系统的 URL 结构是否能对应。不能对应的要做映射表。
- 不可替代的功能。原系统有哪些功能是新系统没有的（比如特定的表单、会员逻辑）。
二、字段映射
两个系统的字段名和结构通常不同。先做一张映射表：
| 旧字段 | 新字段 | 处理 |
|---|---|---|
| post_title | title | 直接对应 |
| post_content | body | 需处理图片路径 |
| post_date | published_at | 格式转换 |
| category | category_id | 需建栏目映射 |
| tags | tag_ids | 需拆分关联表 |
图片路径是最容易出问题的：旧站可能是 /wp-content/uploads/2020/01/a.jpg，新站是 /uploads/a.jpg。要么保持目录结构，要么批量替换正文里的路径。
三、URL 映射
三种情况：
- 结构一致：只改域名，最省事。
- 规则不同：做映射表，生成 301 规则。
- 无法对应：旧 URL 301 到最相关的栏目页。
映射表建议用 CSV 维护，字段是"旧 URL, 新 URL, 状态"。几千条也能处理。
四、迁移的四种方式
| 方式 | 适用 | 风险 |
|---|---|---|
| 官方导入工具 | 两系统之间有插件 | 低，但可能丢字段 |
| 写脚本导入 | 数据量大、结构复杂 | 中，需充分测试 |
| CSV 中转 | 数据结构简单 | 低，但耗时长 |
| 手工重录 | 内容少于 50 条 | 低，但不现实 |
数据量超过 500 条，建议写脚本。先拿 10 条测试，确认字段、图片、标签都对，再跑全量。
五、迁移的执行顺序
- 新站部署在测试域名，装好系统。
- 导入 10 条测试数据，检查展示效果。
- 跑全量导入，核对总数。
- 处理图片（下载、压缩、替换路径）。
- 配置 301 规则。
- 全站检查：首页、列表、详情、标签、搜索。
- 切换域名，观察日志。
六、迁移后的两周
重点盯三件事：
- 404 报告：有没有漏掉的 URL 映射。
- 抓取频次：是否快速恢复。
- 索引量：新旧页面的替换是否顺利。
通常两到四周稳定。如果一个月后索引量仍大幅低于迁移前，检查是否有大量页面返回 404 或内容缺失。
图片迁移最容易被低估
老站的图片往往散在多个目录，还有一部分是外链图床。迁移前先跑一遍全站图片清单，把外链图片下载回本地，否则原图床一关，文章里的图全变红叉。
顺带做一次压缩和格式转换，把历史遗留的几 MB 大图换成 WebP。迁移是唯一一次能低成本清理历史包袱的机会。
迁移后的内容校对
随机抽二十篇，逐篇对比新旧版本的正文长度、图片数量、内链数量、表格是否完整。富文本编辑器之间的转换最容易丢表格和列表样式。
正式迁移前，先做一次只读演练
把整站复制到测试域名，关闭写入，按正式流程走一遍：栏目、文章、图片、附件、表单、伪静态、301、sitemap。记录每一步的耗时和报错，正式迁移时照同一顺序执行，出错也知道该回退到哪一步。
演练时重点看三处：老 URL 是否都能跳到新地址、图片是否还在原路径、后台编辑能否正常保存。这三处没问题，迁移风险就少了一大半。
回滚方案要写清楚：数据库怎么恢复、文件怎么回退、DNS 怎么切回、需要多久。迁移前在测试环境真的回滚一次，确认备份可用，再动正式站。
迁移完成后保留旧站一周，确认 301、表单、邮件和支付都正常，再关服务器。
迁移后保留旧站一周，确认无误再关。
常见问题
能不能两个系统并行
可以，但要避免内容重复。建议新站加 noindex，切换时再放开。
图片要不要重新上传
建议重新上传并压缩，顺便优化体积。直接搬旧图，会把历史遗留的大图一起带过来。
迁移要不要停站
不需要。用 DNS 切换，配合低 TTL，可以做到几乎无感。
迁移的通用流程，见网站迁移不丢数据。
