从Kentico迁移至Drupal：求迁移路径及内容迁移流程经验分享

一、站点结构迁移路径 #

• 先摸透Kentico现有家底：把Kentico里的页面类型、内容分类（Categories/Tags）、权限角色、导航菜单全部整理成清单，对应到Drupal的核心概念——比如Kentico的Page Types对应Drupal的Content Types，Web Parts对应Blocks或Paragraphs，分类直接映射成Drupal的术语集。
• 优先复用Drupal原生能力：别为了复刻Kentico的小众功能搞自定义模块，比如Kentico的新闻类型直接在Drupal建对应Content Type，字段一一匹配（文本、富文本、日期、媒体字段等）；导航结构直接导入Drupal菜单，减少后期维护成本。
• 提前规划URL兼容：把Kentico所有页面的URL导出成表格，在Drupal里用Pathauto配置别名规则，或者批量导入URL别名，确保旧URL能301重定向到新URL，保住SEO权重。

二、内容迁移路径 #

• 拒绝手动迁移，选对工具：30000页的规模，手动导纯属浪费时间，推荐：
  • Drupal Migrate API：写自定义迁移模块，直接连Kentico数据库（或者调用Kentico API）拉取数据，灵活性拉满，适合复杂内容结构。
  • 辅助模块搭配用：Migrate Plus、Migrate Tools能简化迁移配置，不用从零写代码；如果有大量图片、附件，用Media Migration模块处理媒体文件的迁移和实体引用。
• 分批迁移降低风险：别一次性全导，先迁核心内容（新闻、产品页），再迁次要内容（归档、帮助文档），每批迁完立刻核对数量、字段完整性，出问题及时回滚。
• 清洗富文本内容：Kentico富文本编辑器生成的HTML大概率和Drupal的CKEditor不兼容，迁移时要做标签清洗——比如替换Kentico专属的样式标签、自定义短代码，统一成Drupal支持的标准HTML，避免前端显示乱码。

三、迁移流程具体细节 #

1. 准备阶段 #

• 备份Kentico的数据库和所有媒体文件，迁移前务必做全量备份，防止数据丢了哭都来不及。
• 搭一个和生产环境完全一致的Drupal测试站，模块、主题、配置都对齐，先在测试环境跑通迁移流程。
• 写好结构映射文档：明确每个Kentico字段对应Drupal的哪个字段，比如DocumentName对应Drupal的Title，DocumentBody对应Body，避免迁移时字段对应错。

2. 数据提取与转换 #

• 用Migrate API连接Kentico数据库，写SQL查询提取有效数据——记得过滤草稿、已删除的页面，别把垃圾数据导进来。
• 转换数据格式：比如Kentico的日期格式转成Drupal的时间戳，媒体文件路径转成Drupal的媒体实体引用，分类标签转成术语引用字段。

3. 导入与验证 #

• 用Drush命令执行迁移：drush migrate:import --group=kentico_migration（自定义你的迁移组名），全程看日志，有错误及时排查。
• 验证要细致：核对页面总数是否和Kentico一致，字段内容有没有缺漏，富文本显示是否正常，媒体能不能打开，URL别名是否正确。
• 测试权限：模拟不同角色用户访问页面，确保权限和Kentico一致，别出现管理员看不到内容或者普通用户能改内容的情况。

4. 上线前准备 #

• 配置301重定向：把之前导出的旧URL和新URL对应起来，用Redirect模块批量导入重定向规则，用户访问旧链接能自动跳转到新页面。
• 对齐前端样式：对比Kentico和Drupal的页面样式，调整主题CSS，保证视觉效果一致，别让用户觉得换了个网站。
• 性能优化：30000页的站点必须开缓存，比如用Redis或Memcached做后端缓存，配置视图缓存、页面缓存，避免上线后页面加载慢。

5. 上线与收尾 #

• 切换域名解析到Drupal服务器，同时盯着服务器负载和访问日志，有异常立刻回滚。
• 上线后一周内每天抽查内容，修复遗漏或错误的迁移数据，收集用户反馈，及时调整。

内容的提问来源于stack exchange，提问作者Bernie Pineau