一个做生鲜配送的客户找到我们：微信端小程序跑了两年，功能成熟，现在想再做一个支付宝端的小程序，是不是复制粘贴就行？做支付宝小程序开发的迁移，从来不是复制粘贴。看完他的代码我给了结论：核心业务逻辑能留，外围要动的地方不少。迁移不是复制粘贴，今天把这份改造清单摊开，正在盘算这件事的可以对照着估成本。
必须重写的三块
第一块是登录体系。微信端用微信授权加手机号，支付宝端要换成支付宝授权，用户体系得做打通设计，同一个手机号在两端要识别为同一个人，不然会员数据就劈叉了。第二块是支付。微信支付的接口调用、回调通知、退款流程全部要按支付宝的规范重写，花呗、余额这些支付方式要不要开，也在这步定。第三块是云服务和第三方插件。微信云开发的功能、公众号模板消息、微信地图选点，都得换成支付宝生态里的对应物，找不到对应的就自己搭。
页面和组件，差异比想象中细
两端的组件库大体相似但细节不同：导航栏样式、弹窗交互、分享卡片的结构都不一样，照搬过来的页面总会有些别扭。更要紧的是设计取向，支付宝用户目的性强，页面要更直接，微信端那种靠内容种草引导的页面结构，搬过去转化率会打折。我们的做法是业务流程层复用，表现层按两端各自的规范重排，多花的工期换来的是各端体验都在线。
- 先做一次源码评估，判断业务逻辑层的复用比例，通常能到六七成
- 列一张接口差异清单，逐项标注重写、适配、复用
- 两端用户体系统一方案要提前定，别上线后才发现会员对不上
工期和成本，心里有杆秤
迁移的报价区间取决于复用率。多端框架写的项目迁移最省，两三周能搞定，成本大概是新建的一半；原生写的项目，业务层能复用但框架层要重构，四到六周常见。有个坑要提醒：手里没有源码的，迁移无从谈起，有些商家当年做完项目源码被服务商攥着，想迁都迁不动，这又绕回合同里源码归属的老话题。
迁移还有个容易忘的点：两端的运营数据要分开设口径，别拿一端的后台习惯去看另一端，指标名字相近、统计口径不同，误读数据是迁移后头一个月最常见的坑，交接文档里把口径写明白。
给两条实在建议：一是迁移前先做付费评估，让技术团队看完代码再给结论，靠谱的团队会告诉你重写和改造哪个更便宜，有时候重写反而省；二是迁移完成后别急着下线旧端，两端并行跑一个月，确认数据对得上、支付没漏单再收尾。拿不准的可以把源码情况发给比格网络这类两端都做过的团队做个评估，结论很具体，比网上查资料快。支付宝小程序开发的方案怎么定，最终要听自己生意的。
