3、迁移前的准备工作：评估现有系统、制定迁移计划、搭建测试环境

说实话，很多团队在迁移这件事上栽跟头，不是技术不行，而是准备工作没做到位。我见过太多人一上来就撸代码，结果改到一半发现系统依赖太深，不得不回滚。嗯，咱们今天就把这步走稳了。

3.1 评估现有系统：先摸清家底

你想想看，一个跑了好几年的 Classic 系统，里面藏着多少「历史遗留」？我接手过一个项目，光配置文件就两千多行，里面还有三年前临时加的补丁。所以第一步，得把家底摸清楚。

3.1.1 代码层面的评估

我个人习惯先做这几件事：

• 统计代码量：Classic 组件有多少个？页面有多少？别凭感觉，用工具扫一遍。
• 识别核心模块：哪些是业务主流程？哪些是边缘功能？优先级要分清楚。
• 检查第三方依赖：有没有用了不兼容 Adaptive 的库？比如某些老旧的 jQuery 插件。

3.1.2 数据层面的评估

数据迁移往往比代码迁移更头疼。你需要搞清楚：

• 数据存储方式：LocalStorage？IndexedDB？还是后端 API？
• 数据格式：有没有自定义序列化？日期格式统一吗？
• 数据量级：几百条还是几百万条？这决定了迁移策略。

3.2 制定迁移计划：别想一口吃成胖子

说白了，迁移就是个「拆解」的过程。把一个大问题拆成小问题，逐个击破。我建议分三步走：

3.2.1 确定迁移策略

常见的策略有三种，我列个表给你对比一下：

策略	适用场景	风险	我的建议
全量迁移	系统小、模块少	高，一旦出问题全盘皆输	不推荐，除非你很有把握
增量迁移	模块独立、可分批	中，但周期长	大部分项目选这个
并行运行	不能停机的系统	低，但维护成本高	金融、医疗类项目首选

我个人比较倾向「增量迁移 + 并行运行」的组合。先挑一个非核心模块练手，跑通了再推其他模块。

3.2.2 制定时间表

别把时间排太紧。我见过一个项目，老板说「两周搞定」，结果第四周还在修 bug。合理的节奏应该是：

• 第一周：评估 + 环境搭建 + 小模块试水
• 第二周：核心模块迁移 + 单元测试
• 第三周：集成测试 + 性能调优
• 第四周：灰度发布 + 监控 + 收尾

3.3 搭建测试环境：别在生产环境上试错

这个道理大家都懂，但真做起来容易偷懒。我记得有个同事，觉得「本地测一下就行」，结果上线后样式全乱了。嗯，测试环境不能省。

3.3.1 环境要求

一个合格的测试环境，至少要有这些：

• 独立的服务器/容器：跟开发环境、生产环境隔离
• 真实的数据副本：脱敏后的生产数据，别用假数据
• 相同的网络配置：域名、端口、HTTPS 证书都要一致
• 监控和日志：出问题能快速定位

3.3.2 测试用例设计

测试不是随便点点就完事了。我一般会分这几类：

• 功能测试：每个页面、每个按钮能不能正常工作？
• 兼容性测试：不同浏览器、不同分辨率下表现如何？
• 性能测试：迁移后页面加载速度有没有变慢？
• 回归测试：改了一个模块，其他模块有没有受影响？

这里有个小坑：Classic 和 Adaptive 的渲染机制不同，同样的 CSS 样式可能表现不一样。我建议把视觉对比也纳入测试范围，用截图工具逐页对比。

3.3.3 自动化测试脚本

如果你有精力，写个自动化测试脚本能省不少事。举个简单的例子：

// 用 Puppeteer 做自动化回归测试
const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  
  // 遍历所有页面
  const pages = ['/home', '/about', '/dashboard'];
  for (const route of pages) {
    await page.goto(`http://test-env.com${route}`);
    // 截图保存，用于对比
    await page.screenshot({ path: `screenshots/${route}.png` });
  }
  
  await browser.close();
})();

3.4 最后说两句

准备工作做得好，迁移就成功了一半。我见过太多项目，前期评估不仔细，中期计划不周全，后期测试不到位，最后搞得一团糟。你想想看，与其到时候手忙脚乱，不如现在花点时间把基础打牢。

下一章咱们聊聊「代码层面的迁移实战」，到时候我会拿一个真实项目做例子，一步步拆解。嗯，今天就先到这儿，有问题随时交流。