那今天就让我们来一起聊聊“年久失修的系统到底该如何做迁移？”
鹅厂工程师的看法
1
\dol-数据挖掘工程师/
既然是要收拢下调的运营系统，应该主要功能都有替代平台了。
以我个人收拢/升级改造N个老运营系统的经验，可以从以下几个方面着手：一.收入口：主要有下面两类
二.查出口：主要有
1.调外部api：绝大多数api调用是为了当前平台为了完成自己功能，伴随用户访问的产生的，随着当前平台入口被拦住，这些调用会消失。需要留意平台有无类似cron任务，通过调用外部api给其他平台同步数据/状态，不过这类同步的状态/数据实际随着当前平台没有了访问量，一般也就没用了，不用太关心。
2.数据库被外部系统依赖：这种比较麻烦，只能看配置文件找用到的数据库，再联系paas平台找除当前平台以外的使用方。如果数据库连接信息hardcoding到服务里面，只能是抓包大法了，相对来说抓包和分析也更麻烦。
流程上可以分为以下几个步骤：
先做收入口，没有用户访问/api调用了就关站（关闭页面/api入口，不下线服务，可以通过设置iptable或者其他服务器层面的操作）。
以上问题都木有了，备份代码，服务程序和资源彻底停服。
以上的流程可能会有反复，例如关站了发现有功能，有不少用户暂时没有替代，又要打开。不建议上来就看平台代码，运营平台的特点是逻辑零散，依赖复杂，历史包袱重，从代码梳理ROI太低。
2
\johnson-研发工程师/
1.拔掉网线
2.看谁会找上门若：
没人来找，宣布下线完成
有人来找，插上网线...
找日志或者监控信息，看进站出站流量，搜集页面访问和后台调用情况；没有的话，考虑在前后端配置一些监控来采集信息，然后监测之；找到DB，捋一遍数据的最后更新日期，事务日志等信息，帮助对访问情况做一个大致的估计；通过前序获得的信息，找到用户群体，搞清楚系统的功能，判断是否能下线，讨论下线后的后续接续方案等等....
3
\xavier-开发工程师/
如果是针对收拢下线旧系统迁移用户到新系统的场景，个人建议可以尝试以下几个步骤：
一：信息收集
系统日志收集分析，对旧系统做一些日志埋点，识别系统的高频功能操作场景及用户信息。
二：策略及实施
风险管理，识别下线过程可能存在的风险点，并制定相应的应对措施。
注意事项：
考虑到用户可能的迁移成本，下线的过程可能存在反复，要有相应的措施预案，耐心协助用户顺利完成迁移。
4
\esword-架构工程师/
1.透视出系统页面/API与调用用户的关系，重新管理用户组
2.重新开发一套系统和接口，灰度关闭旧接口
5
\sai-开发工程师/
1、通过日志分析平台，找到最近3个月的核心API+访问IP
-根据API访问排行，着重从访问量大的接口开始，做为核心API
-访问IP是为了找到访问方，便于下面的统一拉群通知
-如果现状没有接入日志分析平台，可以先从后端增加一些简单的日志：API名称、访问IP、输出输出日志
2、拆分系统功能类型：从任务流的设计上看，系统任务分为两大类：同步任务，异步任务。
-同步任务：一个任务接口内，直接获取到执行结果
-异步任务：创建任务、监控任务执行结果
二、进一步了解功能：通过绘制流程图、DB日志、代码日志加深系统理解
1、用流程图梳理：核心API内的大致访问关系链，加深对系统链路的理解
2、通过DB的访问日志，可以找到使用的表，通过表结构和数据内容进一步了解系统功能
如果是云数据库，以腾讯云数据库为例，可以在控制台导出后端链接数据库的日志（增删改查日志）
3、在核心API内，增加详细日志
-当前系统访问其他外部API打印日志
一定要打印输入输出日志，切换一旦遇到异常，可以快速比对处理
-核心API内不，补充更多详细日志，加深对系统功能理解
1、下线前
-API用户：根据IP在公司的服务器管理平台上找到服务器负责人，拉群通知
-WEB用户：强制弹窗提示公告，当天用户使用的时候，需要点击确认知晓
2、下线中
-整理替换指引，给到用户做参考。
比如：api替换指引，WEB页面替换指引
-统计当天访问量，标记下线切换完成
整理输出访问的在线表格，逐步跟进切换下线结果
6
\keson-生态技术工程师/
可以先本地升级下，更新下系统内核和驱动lib库等，然后再通过迁移工具进行在线迁移升级