这次项目的目标看起来很直接：把一套长期由外包维护的业务系统接回来，部署到自己的服务器，并让生产数据、管理后台、H5 和 Android App 全部继续运行。包含拉卡拉，微信，支付宝等等多方支付平台
真正开始之后才发现，所谓“接回源码”远远不等于“接回系统”。
一套已经运行多年的业务，除了代码，还有数据库结构、上传文件、支付回调、域名解析、证书、App 签名、服务器配置，以及许多藏在旧页面和历史接口中的依赖。任何一个环节没有迁移完整，系统都可能表面能打开，实际却仍在依赖旧环境。
先让系统真正独立运行
第一步不是重写，而是把现有系统的边界梳理清楚。
项目由 uni-app H5、Android App、ASP.NET 后台/API、IIS 和 SQL Server 组成。迁移时将移动端页面与后台接口分目录部署，在同一站点下通过独立路径承载 API，既保留原有调用方式，也避免额外的跨域改造。
同时逐项清理旧服务器依赖：
- 图片和上传资料统一由新环境提供；
- 支付通知与授权回调切换到新接口；
- 数据库连接、证书和密钥从源码中分离；
- 旧域名引用按业务归属逐一判断，不做整批盲目切换；
- 上传文件与数据库分别迁移和校验。
这一步最重要的经验是：数据库并不是系统的全部状态。证件图片、二维码、海报、安装包等文件同样属于生产数据，必须纳入迁移范围。
补全双渠道商户入网
原系统的商户入网能力并不完整：一个渠道只有部分流程，另一个渠道基本没有落地。
最终将两套官方支付渠道整合成一条统一的用户流程：
- 公共资料只填写一次；
- 营业执照、法人证件、经营场景、结算账户等信息统一暂存；
- 根据主体类型动态展示需要的行业、银行和资质字段；
- 一次操作分别提交两个渠道；
- 两个渠道独立记录审核状态和驳回原因；
- 单个渠道失败时可以单独修改和重试，不影响另一个已成功渠道。
为了避免用户填写一半后丢失，流程还增加了数据库草稿、跨设备续填、图片回填和固定步骤跳转。复杂的大表单由此从“一次性提交页面”变成了可以持续恢复的业务流程。
兼容旧数据，而不是覆盖新结构
正式迁移时，旧生产数据库里并不存在后来新增的入网表、行业映射和渠道状态字段。
因此没有直接用旧数据库覆盖新环境，而是先保留旧表和旧数据，再执行增量结构迁移，让历史数据能够继续使用，同时为新功能补齐字段、索引和基础目录。
旧二维码和新官方收款码也保持数据隔离：旧业务仍然能够查询和展示，但不会混入新的官方申请单。这种处理比“全部改成一张新表”更克制，也更适合已经运行多年的生产系统。
修复那些不显眼但会影响交付的问题
迁移过程中还遇到了不少典型的遗留系统问题：
- 后台菜单存在失效页面和空链接；
- 统计页面依赖数据库中不存在的列；
- 图片地址缺少接口路径，刷新后看起来像资料丢失；
- 行业、地区和开户行目录使用了不同编码体系；
- APK 文件已经上传，但 IIS 没有配置对应的静态文件类型；
- 新旧 Android 签名不同，无法直接覆盖安装。
这些问题单独看都不大，却会直接影响最终使用体验。处理方式也尽量遵守一个原则：保留旧表和旧入口，修正实现与映射，不通过删除历史代码来制造“干净”的假象。
Android App 重新交付
完成接口和图片链路调整后，使用当前源码重新构建 Android 正式包，保留原应用名称、图标、包名和版本号，并固定使用自己的签名证书。
出包后进行了多层验证：
- 前后端回归测试通过；
- APK 的包名、版本号和签名正确；
- APK 内置代码与本次编译产物哈希一致；
- 生产 API 地址已经进入安装包；
- 公网重新下载安装包后，文件哈希与本地原包一致。
由于历史 App 的签名不在自己手中，这次选择让旧用户卸载后重新安装。虽然第一次切换会多一步，但从这一版开始，后续版本已经能够持续使用同一套自有证书升级。
最后的结果
最终完成了生产数据库、上传文件、H5、后台接口、支付入网流程和 Android App 的整体交接，新系统不再依赖外包人员掌握的服务器环境。
这次项目没有追求推倒重来，而是在尽可能保留历史业务的前提下，让系统重新变得可理解、可验证、可维护。
回头看，系统迁移最难的部分从来不是“把文件复制过去”，而是找到所有隐含状态，并证明切换之后每一条关键链路仍然成立。
真正的自主可控，也不是手里多了一份源码，而是从数据库、文件、证书、域名到发布流程，每一个关键环节都可以由自己解释、验证和继续维护。