一家做女装批发的客户，两个档口加一个八百平的仓库，老系统是二零一四年装的单机版进销存，主机在仓库办公室墙角，硬盘换过两次。他们要上订货小程序，谈判桌上问的第一句话是：这十年的数据能不能全搬过去。

这个问题不该用能或不能回答。旧数据是分层的，每一层该不该进新系统，各有各的判断依据，而且都能落到数字上。把判断依据摆出来之前先说清一条准绳：衡量某类旧数据要不要搬，看的不是它有多完整，是搬过去之后半年内有没有人真的会点开它。这几条判断最好在小程序定制开发的需求确认会之前就做完，等原型画出来再返工，改的就不只是数据表了。

条件一：旧库能不能直连，决定后面所有选项的范围

这一条排在最前，因为它一票否决其余讨论。三种情形对应三种结论。第一种，老系统用的是 Access 或者 SQL Server Express，能从主机上拿到 mdb 或 bak 文件，字段级映射可行，迁移主体工作量通常落在五到八个人日。第二种，数据库拿不到，只能用前台报表导出 Excel，导出来的表里金额带千分位、款号列夹着换行符、表头是合并单元格，这种情况下只能搬主数据，明细流水改成按月汇总。第三种，加密狗锁库、原厂商已经联系不上、单据只有打印件，那就别谈迁移了，直接走期初建账，两到三个人日搞定，比撬旧库划算得多。落到哪一种，直接决定小程序定制开发报价单上数据迁移那一栏是写八千还是写三万。

这条的边界在于：能导出不等于能用。判定标准是打开导出的明细表，看单据号、行号、款号、颜色、尺码、数量、单价这七个字段是否齐全。缺任意一个，行级迁移就得靠人工补，成本按缺失字段数乘以行数估。明细超过十万行还缺字段的，直接放弃行级迁移，转汇总层。

条件二：款号动销率低于一成，历史款就不该进新库

做了十年的女装档口，累计款号大多在八千到一万五千个之间，而近十二个月有出货记录的通常只有六百到一千二百个，占比百分之八到百分之十二。剩下那九成款号里，绝大多数连样衣都找不到了。

可执行的判断是取两个集合的并集：近十八个月有动销的款号，加上当前结存大于零的款号（压在货架上两年没动，那也还得卖）。两者合并一般是一千五到两千五百个，占全量的一成半到两成，这一批进新库。剩下的无结存且二十四个月无动销的，导成 CSV 归档到对象存储，不进业务表。

为什么要卡这道：订货小程序的搜索框里如果八千个款号全在，业务员打三个字弹出四十条结果，选错颜色码的概率反而比旧系统更高。数据搬得越全，前台越难用，这在款色码维度上体现得最明显。这条的例外是常年翻单的经典款，打底衫、白衬衫、基础款西装外套这类，可能两年没动突然返单，需要人工打上常销标签保留，一般在五十到一百二十个之间，别指望规则自动识别。

条件三：账实差异率超过一成，库存结存一定不能搬

判断方法很朴素：随机抽三个货架，或者抽三十个款色码，拿实盘数对系统结存。差异率低于百分之三，可以按系统结存导入，个别差异用抽盘结果覆盖；百分之三到百分之十，只导款色码档案，数量一律以盘点日实盘为准；超过百分之十，结存坚决不搬，并且切换后旧系统的库存报表也要一并停掉，两套数并行只会让业务员两套都不信。

服装批发的差异来源是固定的那几样：走份拆包、调色调码、样衣借出未登记、退货回来先上架后补单。实测差异率常在百分之五到百分之十五之间，而且尺码维度比款号维度差得多，款号总量对得上、S 码和 M 码互相串的情况极其普遍。配套的节奏约束是盘点日的选择：一个两千款色码的仓库，两个人盘一天半到两天，这个时间只能放在订货淡季，换季订货会前后各十天排盘点等于让项目直接停摆。

条件四：欠款搬余额还是搬逐笔，看账龄结构

应收这块必须搬，争议只在颗粒度。判断依据是账龄超过一百八十天的欠款占总应收的比例。低于百分之十五，且手上有客户签字的对账单，搬一行期初余额就够，一个人日；百分之十五到百分之三十，近十二个月的逐笔搬、更早的合并成一行期初结转；超过百分之三十，或者存在客户不认账的挂账，那就得全部逐笔重建，按每个客户二十到四十分钟估，八十个客户大约四到六个人日。

这里有条容易忽略的边界：批发赊账普遍有款清抹零的口头惯例，旧系统里沉淀成一堆几十块钱的挂账尾巴。迁移前要先做一次抹零清理，设个阈值，比如五十元以内一次性核销，让客户余额干净地落地。否则新做的对账页面上每个客户后面都吊着零头，业务员第一次打开就会认定这系统算错了，后面再准的数也没人信。

条件五：历史流水搬多久，由退换货期和订货会周期倒推

批发端的调换货窗口通常是七到十五天，个别做品牌代理的有季末退货政策，纯追溯需求三个月足够。真正拉长时间跨度的是订货会：业务要看上一季和去年同期的客户拿货结构，这就要求二十四个月。两者取大，默认二十四个月进业务库，更早的做只读归档页，甚至存成 Excel 挂在内网都行。

这笔账可以算清楚。全量十年流水大约六十万到一百二十万行，迁移加清洗加验证在八到十二个人日；只搬二十四个月，十万到二十万行，三到四个人日。差出来的五到八个人日，按一千二到一千八一个人日算，就是六千到一万四。判断值不值的办法是问业务员或者翻旧系统的查询记录：过去半年查过两年以前单据的次数，超过十次才值得掏这笔钱，实际情况多数是零到两次。

条件六：什么规模下不该做小程序定制开发

这条是反向的。同时满足三条以上就别走定制：单档口一到三个人、月订单不到两百单、在售款色码低于五百、没有多仓调拨、账期政策全店一个标准、不做代发。这种体量用标品 SaaS 更合适，年费三千到八千，两周能开起来，历史数据用它自带的模板导入即可，不必为此启动小程序定制开发。

倒向定制的条件也很清楚：多仓或多档口带调拨、要做代发（得对接快递面单和上游供应商）、账期与折扣按客户等级分层、需要和已有财务或 ERP 打通、月订单过两千。满足其中三条，小程序定制开发的报价一般在六万到十五万，工期四十五到七十天，这笔投入能收回来。

中间地带最难判——月订单在两百到两千之间的档口，光看订单量得不出结论。这时候的判断标准换一个：有没有哪条业务流程是标品改不动的。服装批发最典型的就是走份规则，一手五件三色、跳码、拼手、按手补色，这套逻辑标品 SaaS 几乎都做不利索，只要业务离不开它，判断就落到定制这一边，跟订单量无关。

最容易被误判的一条：款式图的对齐率

前面几条条件，只要肯动手核一遍，答案都不难得出。真正在项目中途爆掉的是图片，因为它在报价单上通常被算成零人日——大家默认图片会跟着款号自动搬过去。

实际情况是：旧系统的图片压根不在数据库里，躺在档口那台机器的共享文件夹，目录叫三月新款拍照，文件名是相机自动生成的 DSC 编号，和款号之间没有强关联；有关联的那部分靠的是路径字段，主机一换、盘符一变，链接全断。一万五千个历史款对应四万到八万张图，能自动对上款号的通常只有三成到四成半，其中分辨率合格的还得再打折——订货小程序的列表主图短边一般要求八百像素以上，十年前用卡片机在档口拍的图，很多连这个都不够。

而订货小程序对图片的要求比旧系统高得多，列表主图、分色图、面料细节图缺一张，前台列表就露一块白，业务员宁可发微信也不愿意用。人工补图按每张十五到二十五秒算，就算只补一千五百个在售款、每款三张，也是二十到三十个小时，这还没算重新拍照和抠图的时间。所以在签小程序定制开发合同之前，要把图片对齐率写成一个可验收的数字：在售款主图对齐不低于百分之九十五，未对齐部分由哪一方在多少个工作日内补齐，补不齐怎么算。把这一行写进验收条款，比在合同里写含历史数据迁移这七个字管用得多。