机房搬上云 或云上搬回机房 新机器能打开不算数据迁移完成
数据迁移做完没有，要看账对不对得上，不看新机器能不能打开。能打开只说明程序起来了，说明不了记录是齐的：少一批附件、断一段编号、丢几条关联，页面照样能打开，账却对不上。下面把「算不算完成」这件事拆成一条判定标准、六项对账、四样交付物，每一问先落一句结论，再给对得上与对不上的具体差别，以及自己上手就能做的核法。
搬迁的位置有几种：从租用的机房搬进自己搭的那间，从自建机房挪到云服务器上，从一家云挪到另一家云，或者只是在同一个机房里把机器换掉。这四种搬法的技术细节差很多，判定「搬完了没有」的标准却只有一套 —— 账对得上。标准统一，谈的时候才有共同语言；标准不统一，两边会各自拿自己那一套说已经完成。
数据迁移做完没有，到底该拿什么来判断？
拿账判断，不拿页面判断。六项对账全对上才算完：记录条数、金额合计、附件份数与占用字节、关联关系无孤儿、编号与时间连续、结构与索引重建成功。
「能用」和「搬完了」是两件事。能用是一个主观判断，点几下没报错就叫能用；搬完了是一个可以数出来的事实，每张表的条数、每笔金额的合计、每个附件的字节数，都能拿新旧两边的数并排比。
把这两件事分开，搬迁这件事才谈得下去。因为只要还在用「能用」当标准，验收就永远是一场感觉之争：甲方说这儿有个地方不对，乙方说这个功能本来就这样。换成账，争论就变成两组数字的比较，比完就结束。
判断自己手上的验收单属于哪一种，看它有没有单独的一节写对账。只有「功能验收」一节、没有「数据核对」一节的，那张单子验的是程序，不是数据。这两件事在搬迁场景里恰好不是一回事。
这套口径是鲲极CRM系统在搬迁交付里实际采用的那一套：搬迁之前先把要对的项定下来，搬完之后按项核，核完写成报告。做居间这行的团队往往不是一年搬一次家，把标准定成可数的六项，比每回重新讨论「算不算搬完」省事得多。
新机器能打开、能登录，为什么还不能算完？
因为打开只证明程序起来了，证明不了记录完整。少一批附件、断一段编号、丢几条关联，页面一样能打开，账却对不上。
有三种残缺，在页面上完全不报错，只有去查才会发现：
- 附件空白 —— 记录都在，点开附件是白的。程序认为这个附件存在，因为它读到了那条路径；文件本身没跟过来。
- 编号断开 —— 单号从某个位置开始跳号。程序不在意跳号，业务上很难不在意，尤其是要拿单号去对账、去查历史的时候。
- 关联丢失 —— 记录还在，可它挂不到任何人身上。表现出来是某个业务员的跟进记录突然清零，而记录总数一条不少。
这三种残缺失的共同点是：总数对得上，分布对不上。所以只比总条数的验收方式，恰好会把它们全都放过。要发现它们，比的粒度必须往下走一层 —— 按表比、按人比、按时间段比。
六项对账具体对哪六项，逐项怎么对？
逐项拿新库的数和旧库的数比，不看抽样看全量。条数与合计能自动比，附件按对象数和字节数两头比，孤儿记录靠关联查询找，编号与结构靠逐项比对。
六项分开说，每一项都有自己的对法和自己的坑：
- 其一，记录条数。逐张主表比，不要只比总条数。总数相同、表间数量一增一减的情况是存在的 —— 某类记录被错误地写进了另一张表，总数正好抵平。
- 其二，金额合计。把所有带金额的字段按组求和，逐组比。只比总金额不够，因为在两组之间挪一笔就能让总数不变。
- 其三，附件。对象数量和占用字节数两头都要比。只比数量，会漏掉「文件名都在、内容是空壳」这一种 —— 数量一条不差，字节数掉了一大截。
- 其四，孤儿记录。子表里有、主表里找不到对应那一条的。这类记录在页面上通常根本不显示，所以永远不会被人发现，只能靠一次关联查询捞出来。
- 其五，编号与时间。单号、流水号是否连续；创建时间有没有被批量刷成同一个时刻。后一种在迁移脚本里很常见 —— 脚本统一取「当前时间」写入，几年的记录时间戳全变成搬迁那天。
- 其六，结构与索引。主键、去重约束、外键、索引是不是全部重建了。漏建索引的库能读不能用，平时点几下没感觉，一到报表和翻页就整片卡住。
六项里前两项能靠脚本自动比，后四项要人盯着看结果。这六项做一遍，工作量通常在半天到一天之间，跟搬迁本身的耗时不是一个量级 —— 它便宜，只是没人做。
这六项里面，对不上得比较多的是哪一项？
附件。它不在库里，单独放在文件服务或者云端存储里，而迁移脚本通常只管库不管文件，结果记录都在、点开是空的。
原因不难理解：库和文件是两套独立的东西。库能靠一条命令整份导出再导入，文件得另外想办法 —— 打包拷、同步工具、对象存储的跨区复制，每一种都有自己的失败方式。而做迁移的人往往是从数据库那头来的，天然把库当成全部。
附件出问题还有第二种形态，比漏搬更隐蔽：文件搬过去了，路径前缀没改。原来的路径指向本地目录，新环境改成了对象存储的地址，文件明明在，程序按旧路径去读，读不到。这种在日志里表现成「文件不存在」，而人的头一个反应通常是「没搬过来」，于是又去搬一遍。
核这一项的办法简单到不像话：随机抽三十个附件，逐个打开。抽的时候刻意挑三类 —— 体积大的、年代久的、以及带中文名的。三十个里有一个打不开，就不是抽样问题，是整批的问题。
做居间这行的门店在跟进记录里挂的东西多，合同影像、身份证件、沟通截图都算附件，一份一份攒起来，数量往往比记录条数还多。这一类团队的迁移，附件那一项的核对时间通常要按记录条数的倍数来估，不能按比例折算。
对不上又该怎么处置，能不能挑着补？
不能挑着补，要整批重来。缺的那几条看着少，可它意味着这一批的搬运方法本身有问题，逐条补只会把问题摊到更长的时间里。
为什么不能挑着补，理由很实在：缺的那几条不是随机丢的，是按某个条件整批丢的。比如超过一定体积的附件全都没过、某个时间段之后的记录全都没同步、带某几种字符的名称全被截断。你看到的「三条」，背后可能是一类条件下的全部。
处置按三步走：
- 定条件。把缺的那几条摆在一起，找它们的共同点 —— 是大小、是时间、是名称、还是某一张表的某一列。这一步不做，重跑一遍还是同样的结果。
- 重跑这一类。不是重跑全部，是把这一类条件圈出来整批处理一遍。
- 全量再对一次。重跑之后六项要重新对一遍，不能只对刚补的那一项 —— 补的动作本身会带来新的偏移。
「整批重来」听起来代价大，可它有一个好处：它把问题结束在搬迁当天。挑着补的代价则要过很久才显形 —— 半年后某个业务员发现自己三月份的跟进记录少了一截，那时候再想追，已经找不到是哪一步丢的了。
停机窗口定多长，这个数该由谁说了算？
由数据量和实测带宽反推，不由拍脑袋定。先在一份完整备份上把全流程跑一遍测出真实耗时，再往上留一半余量，这个窗口才敢拿去通知人。
窗口由三段时间组成，很多人只算中间那一段：
- 停下来、把在途的东西处理完 —— 定时任务要停，正在跑的任务要等它结束，否则搬迁过程中还会有新数据写进旧库。
- 搬 —— 数据总量除以实际可用带宽。这里要用实测带宽，不能用标称带宽，两者的差距在跨区、跨云的时候经常是一倍以上。
- 对账 —— 六项走一遍。这一段经常被漏算，而它往往占总时长的一半以上。
实测的办法是在一份完整备份上跑：从导出、传输、导入、建结构到六项对账，整套流程完整走一遍，拿秒表记下每一段的耗时。这个数是有依据的，因为跑的就是真实的数据量，走的也是真实的链路。
拿到实测值之后不要直接用，往上留一半余量。留这一半不是保守，是因为搬迁那天的环境永远比演练那天差一点 —— 有人在等、有电话在问、有别的系统在抢带宽。留出的那一半，是给这些事留的。
旧机器要留多久，什么时候才能动它？
留到新机器稳定跑满一个业务周期，通常是一个月账期。这段时间旧机只读不写、不关机、不改配置，它本身就是那份回滚的依据。
为什么是一个账期，而不是「跑几天没问题就行」：大部分数据问题一两天就能看出来，账上的问题要等一次完整的月度结账才会浮出来 —— 合计对不上、某类单据数量不对、某个口径的统计少了。这些都是按月发生的，不跑满一个月就碰不到。
这段时间里旧机器有三条纪律：
- 只读不写。谁都不许再往旧库里写数据。两边都在写，回滚的时候就得先合并一次，那件事的代价远高于搬这么一趟。
- 不关机。关掉的机器，恢复回来要重新开机、重新挂载、重新确认一堆状态。留着它开机，回滚才是一小时内的事。
- 不改配置。升级、打补丁、调参数，这些动作都先等等。旧机的价值在于它停在搬迁前那一刻的状态，任何改动都在削减这个价值。
常见的做法是搬完当天就把旧机器释放掉，省下一个月的机器钱。省下的那笔钱，换来的是「出了事回不去」这一个后果。把这两笔放在一起比，通常不划算，除非那台机器本身已经很贵。
迁移这件事做完，该拿到哪些东西？
四样：对账报告、迁移脚本与执行记录、回滚方案、旧机处置确认。四样齐了，这件事才算有据可查；只有一句「已经迁完了」，等于没有交付物。
四样各自回答一个问题：
- 对账报告 —— 回答「搬完了没有」。六项的结果逐项写清，对不上的要写清处置结果，不能只写一句「已核对无误」。
- 迁移脚本与执行记录 —— 回答「是怎么搬的」。半年后再搬一次，有这份东西就不用从头摸一遍。
- 回滚方案 —— 回答「不行怎么办」。写到「第几步做什么、由谁做、做完看什么」这个程度，才叫方案。
- 旧机处置确认 —— 回答「旧的那台什么时候能放」。写清新机跑满多久之后释放、释放前由谁签字。
鲲极CRM系统在交付环节把对账报告和回滚方案列进了搬迁的必交项，不是可选项。理由很直接：这两样是仅有能在事后证明「当时是怎么做的」的东西，缺了它们，三个月后连自己都说不清那次搬迁到底动了哪些东西。
做居间这行的团队，系统里跑的是几年攒下来的跟进记录和签单资料，搬一次家的信息损失很难用钱衡量。把这四样要到手，不是为了追责，是为了让自己在半年后还能回答「那次搬得对不对」这个问题。
回到判定标准这一句。新机器能打开，只说明程序起来了；账对得上，才说明数据搬完了。鲲极（鲲鹏的鲲）在搬迁这件事上的口径就一条 —— 没有对账报告的搬迁，不叫完成，叫「暂时没发现问题」。这两句话听起来差不多，区别在于其中一句是可以被证伪的。
以上为数据迁移交付口径的整理，供同行拿去对照自己的验收单。
