Concrete5的架构在老化，扩展性也有限。想迁到WordPress，问题不在于"能不能迁"，而在于找谁迁——选错了，数据损坏、页面结构崩掉、SEO排名丢失，都是真实会发生的事。
市面上说能做这件事的公司不少。有的确实理解技术深度，有的只是试着做做，还有的会留下技术债，让你在接下来几个月里持续收拾残局。
两个CMS，两套完全不同的内容模型
Concrete5是一套完整的CMS，有自己的架构、内容模型、页面组织方式，以及处理区块和模板的特定方法。WordPress则是另一套逻辑，用文章和文章元数据来组织内容。
问题就出在这里。两者的页面层级结构不同，区块系统完全不同。你没法简单地导出再导入。
迁移真正要做的事包括：
- 理解Concrete5的内容模型
- 正确导出Concrete5中的数据
- 把数据转换成WordPress格式
- 正确处理区块转换
- 重建页面结构
- 迁移自定义字段和元数据
- 搭建正确的WordPress结构
- 处理自定义属性
- 迁移用户账号
- 为SEO保留URL结构
- 完整测试每一个环节
任何一步出错，结果就是内容丢失、页面结构损坏，或者页面之间的关系断裂。
为什么Concrete5的迁移格外棘手
Concrete5的生态是有限的。插件版图很小，想找新功能的扩展很困难，平台上的开发速度慢，而且想找到专精Concrete5的开发者几乎不可能。
WordPress正好相反。它是全球最流行的CMS，生态庞大，有成千上万的插件和开发者，创新持续发生，开发速度快，选择不受限制。
这种反差恰恰是迁移难度的来源。一边是封闭且人才稀缺的旧系统，一边是开放且迭代迅速的庞大生态，中间的转换层没有现成工具可以一键完成。
技术难点集中在四个地方
内容模型差异。两套系统的内容模型完全不同，理解双方是前提，数据转换并不轻松。
页面层级复杂度。Concrete5有自己组织页面层级的方式，WordPress的做法不一样，正确重建层级需要同时吃透两套系统。
区块系统架构。Concrete5有自己的区块系统，WordPress用的是另一套区块架构，转换区块要求对两者都有深入理解。
自定义字段处理。Concrete5有自定义字段，这部分同样需要在迁移中妥善处理。
好的迁移服务商具备几个共同特征：理解Concrete5的架构，理解WordPress的结构，能合理规划迁移，测试充分，执行干净，并在上线后提供支持。这份清单要找的，就是这样的公司。
热门跟贴