PG官网

  一个很典型的换主体场景是这样的。做连锁零售的品牌把小程序从老公司换到新公司，行政提交完主体变更，觉得营业执照一换，事情就结束了。上线第二周，客服群里开始出现同一类问题。老会员打开小程序，登录状态没了，重新授权后变成新用户，积分和优惠券归零。有人想查两年前的订单，页面显示暂无记录。申请退款的客户被客服告知，这笔钱在原公司商户号里，要走另一套流程。老板拿着手机问技术负责人，微信不是支持换主体吗，为什么用户和订单都带不走。

  问题不在微信支持不支持，在于很多公司把换主体理解成了一件事。微信平台上有三条路，主体变更、账号迁移、重新注册，名字听着差不多，结果差得很远。再加上用户身份、支付商户号、备案、合同这些平台外的资产，任何一项没接上，用户看到的就是登录失效、订单消失、退款无门。

一、先分清主体变更和账号迁移，别把两件事混着做

  微信官方文档把两件事分得很清楚。主体变更在同一个账号里完成，AppID 不变，小程序不会被注销，只是运营权限和主体信息换人。账号迁移是在两个小程序之间做，AppID 会变，原小程序迁移完成后等于注销，用户再打开旧入口会自动跳到新小程序。

  还有一个更常见的做法，直接拿新营业执照注册一个新小程序。平台眼里它和老程序没有关系，AppID、用户、流量、评价全部从零开始。很多老板把这也叫迁移，后面发现什么都接不上，才知道叫错了。

  三件事的适用场景不同。老品牌继续运营、用户不能丢，优先考虑主体变更。老公司要彻底退出、旧小程序本来就要废弃，才考虑账号迁移。原公司不配合、材料凑不齐，只能新注册，那就要接受用户和订单重新建设。

  很多人听到迁移两个字，以为平台会把东西打包搬过去。平台搬的是账号入口和运营权限，搬不了你服务器里的用户表、订单表，也搬不了微信支付商户号里的交易记录。这三样东西不在一个地方，得分别处理。

  主体变更也有门槛。目标主体不能是个人，原主体和目标主体都要能出材料，小程序不能有未处理的违规和纠纷，广告账户余额要清零，绑定的商户号要符合要求，服务类目要用新主体资质重新审核。这些条件缺一条，流程就卡住。

  账号迁移的限制更硬。原小程序和目标小程序要绑定在同一个开放平台账号下，主体相同或者属于关联主体。迁移完成后原小程序注销，不能恢复。一个目标小程序最多接收五个小程序迁移，完成迁移的目标小程序六个月内不能再次作为原账号发起迁移。

  所以第一步先别急着提交申请，坐下来算一笔账。用户资产值多少钱，历史订单要保留多久，旧商户号还有多少未结算和退款，新主体能不能接住类目和资质。算完再选路，比提交完被驳回再改，省时间。

二、用户带不走，多半是 OpenID、UnionID 和登录体系没接上

  微信里的用户身份不是一个手机号就能说清。OpenID 是用户对某个 AppID 的唯一标识，同一个用户在不同小程序里，OpenID 不一样。UnionID 是用户对某个开放平台账号的唯一标识，同一个开放平台下的应用，UnionID 相同。官方给过一个很直白的公式，微信用户加 AppID 等于 OpenID，微信用户加开放平台账号等于 UnionID。

  主体变更时 AppID 不变，OpenID 也不变。只要小程序的开放平台绑定关系没动，UnionID 同样不变。用户表里的 openid 还能对上，会员等级、积分、优惠券都有机会保留。有人说主体变更后用户丢了，往往是变更过程中换了开放平台账号，或者代码里把 openid 当成了唯一用户 ID，又没有做兼容。

  账号迁移时 AppID 变了，OpenID 一定变。UnionID 要看两个小程序是不是在同一个开放平台账号下。如果原程序和新程序绑在同一个开放平台，UnionID 可以继续保持一致，你可以用 UnionID 把老用户和新用户对上。如果不在同一个开放平台，或者根本没有接 UnionID，老用户的身份就断在这里。

  新注册的小程序更彻底，AppID 是新的，OpenID 是新的，UnionID 也可能换。没有历史 UnionID，没有手机号，没有会员卡号，只靠昵称和头像，基本认不出谁是谁。昵称可以改，头像可以换，同一个人还能有多个微信号。

  想留住用户，数据库里要有一个不依赖微信的稳定用户 ID。手机号、会员卡号，或者你自己生成的账号 ID，都可以。OpenID 只当登录凭证，不当主键。这样换了 AppID，用户重新授权手机号后，还能把老账号找回来。

  老用户的 OpenID 列表要提前导出。主体变更还好，AppID 不变，原表还能用。账号迁移就麻烦，新小程序拿不到老程序的 OpenID，微信也没有提供把旧 OpenID 批量换成新 OpenID 的接口。你只能靠 UnionID 或者用户重新授权手机号来匹配。

  匹配不能偷偷做。把老用户的会员等级、积分、优惠券直接并到新账号，属于个人信息和权益的转移，要让用户知道，必要时得单独同意。隐私政策里的处理者变了，收集范围变了，也要同步更新。用户不同意，老数据只能留在原主体，按约定保管或者删除。

  登录页也要改。换主体期间，老入口和新入口可能同时存在，用户从旧的二维码、旧链接、旧收藏进来，不能直接报错。做一个过渡页，说明服务由哪家公司承接，引导用户重新登录或者授权手机号，比让用户自己猜要好。

三、订单带不走，卡在商户号、合同和开票主体

  订单不是一个可以复制粘贴的文件。一笔订单背后有商品、价格、下单人、支付流水、发票、退款、售后，还有卖这笔货的法律主体。平台换主体，不会把你数据库里的订单表搬走，也不会把微信支付商户号里的交易记录搬到新商户号。

  主体变更时，小程序 AppID 不变，但微信支付商户号要跟新主体对上。原来的商户号如果属于老公司，提交变更前通常要解绑，变更期间支付会停。变更完成后，新主体要重新申请或者绑定自己的商户号。旧商户号里的交易还在，退款接口、对账单、结算账户也还在老主体那边。

  账号迁移时，原小程序注销，原商户号不能继续给新小程序用。目标小程序要单独申请商户号。官方说明里写得很清楚，账号迁移完成后原小程序不可用，商户号仍可继续使用，但目标小程序要收款得另行申请。两套商户号会带来两套结算、两套对账、两套退款权限。

  新注册的小程序更直接，新主体、新 AppID、新商户号，老订单和新订单在系统里就是两个世界。用户在新小程序里看不到老订单，客服也查不到老支付流水，只能回老后台查。

  订单背后的合同也要处理。老订单是老公司和用户之间的买卖或者服务合同，新公司不能因为换了个小程序就自动承接。要把老订单转到新主体，涉及合同权利义务转让，得看合同条款，得通知用户，有的还要用户同意。尤其是预付卡、会员储值、长期服务合同，不能只改一个收款方。

  发票和税务同样分开。老订单的发票由老主体开，收入确认在老主体账上。新订单由新主体开票、确认收入。两边混着开，财务对不上，税务也解释不清。换主体前，财务要先把未开票、未结算、未退款的订单拉一张清单，约定由谁收尾。

  退款是最容易出事的地方。用户在小程序里点退款，新主体没有老商户号的退款权限，只能让用户去找老公司。老公司如果已经注销、账户冻结、负责人失联，退款就卡死。所以老主体注销前，必须把未完结的订单、退款、发票、质保责任处理完，不能先注销再想办法。

  比较稳的做法是留一个过渡期。老主体继续处理历史订单和售后，新主体只接新订单。两边系统通过订单号或者用户 ID 做关联，客服能看到用户在哪边下过单。过渡期多久，看退款周期、质保期和合同约定，不要拍脑袋定一个月。

四、真要换，先把数据、备案、类目和用户告知排成一张表

  换主体不是技术部一个部门的事。老板定商业方案，商务看合同，财务管商户号和发票，技术管 AppID、OpenID、UnionID 和数据库，运营管备案、类目、广告和用户沟通。少一个角色，后面就多一个坑。

  先做资产盘点。把 AppID、原始 ID、开放平台绑定关系、商户号、广告账户、备案号、服务类目、插件、客服系统、订阅消息模板、小程序码、公众号关联、搜索关键词，一项一项列出来。每项写清楚现在挂在哪个主体，换完之后归谁，要不要重新申请。

  用户数据单独列一张表。OpenID、UnionID、手机号、会员等级、积分、优惠券、收货地址、订单号、授权记录、隐私政策版本，哪些能迁，哪些要用户重新授权，哪些必须留在原主体，写清楚。能迁的部分，先做脱敏导出和字段映射，再在新系统里做导入和校验。

  备案要提前办。小程序主体变了，原来的 ICP 备案信息对不上，通常要先把原备案注销，再用新主体重新备案。备案没下来，小程序可能没法正常发布。这个周期要算进计划里，别等到上线前一天才发现卡在管局。

  服务类目要用新主体资质重新申请。老主体有食品经营许可证，新主体没有，食品类目就过不了。老主体有医疗器械资质，新主体没接住，相关功能就得下架。类目和功能对不上，代码审核也会被驳回。

  支付要单独排期。先确认新商户号能正常收款、退款、对账，再解绑老商户号。顺序反了，中间会有一段支付真空。变更期间如果有促销活动，最好避开，或者准备线下收款和人工客服兜底。

  用户告知要提前做。小程序里发公告，公众号推文，客服话术，短信通知，能用的渠道都用上。说清楚为什么换主体，用户权益怎么处理，历史订单去哪查，退款找谁，客服电话是多少。别只发一句系统升级，用户看不懂。

  灰度切换比一刀切稳。先让新主体承接一小部分新用户，跑通登录、下单、支付、退款、开票，再逐步放量。老入口保留一段时间，发现登录失败或者支付异常，能马上切回去。监控要盯登录成功率、支付成功率、退款失败率、订单查询失败率，不要只看系统有没有宕机。

  收尾留一份切换记录。谁在什么时间改了什么配置，旧商户号什么时候解绑，新商户号什么时候生效，备案什么时候下来，用户告知什么时候发，出现什么问题怎么处理。后面再换人接手，这份记录比口口相传管用。