长沙小程序改版前，先确认旧数据能否完整迁移

长沙小程序改版前，旧数据到底能不能完整迁移？这个问题不搞清楚，改版可能变成一次数据丢失事故。先给一句提醒：不要只看新页面效果，先确认旧数据有没有迁移通道。

直接结论：能不能迁移，取决于旧数据存在哪

小程序的数据不是一坨整体。用户信息、订单记录、商品内容、会员积分、聊天消息、页面配置、表单提交记录，分别存在不同位置。有的在微信云开发数据库，有的在自建服务器，有的在第三方平台后台，还有的只存在本地缓存。

改版时能不能迁移，先看数据出口。微信云开发数据库支持导出 JSON 和 CSV，自建 MySQL 可以导 SQL 文件，第三方平台要看后台有没有导出按钮。如果旧系统连导出功能都没有，迁移就无从谈起。

另一个决定因素是数据结构差异。旧版字段叫“user_name”，新版叫“nickName”，直接导入会报错。字段类型也要对齐，旧版手机号存成数字，新版要求字符串，导入时就会丢数据。

长沙小程序改版最容易被忽略的动作：先做数据盘点

很多团队拿到新版需求就开始画页面，等到上线前一天才问旧数据怎么办。这时候开发方只能临时写脚本，脚本跑一半报错，旧数据导不进去，新数据已经开始产生，两边对不上。

数据盘点要落在具体动作上。先让开发方列出旧系统所有数据表，标出每张表的记录条数、字段名、字段类型、是否有外键关联。再让新系统开发方列出目标表结构。两边字段做映射表，逐列核对。

盘点时重点关注三类数据。用户身份数据，比如 openid、unionid、手机号，迁移错了用户就登录不上。交易类数据，比如订单号、支付金额、退款状态，迁移错了对账就乱。内容类数据，比如文章、商品详情、图片链接，迁移错了页面就空白。

风险提示：旧数据里如果有用户上传的图片和视频，迁移时只迁数据库记录不迁文件，新小程序里图片会全部裂开。文件存储路径也要一起迁移。

不同项目类型，迁移难度差别很大

展示型小程序改版，旧数据主要是页面配置和少量表单记录。这类迁移相对简单，导出 JSON 再按新字段导入即可。但要注意旧版页面路径和新版路径不一致，旧链接会 404，需要做重定向。

电商型小程序改版，旧数据涉及商品、订单、库存、优惠券、会员等级。库存和优惠券有有效期和状态，迁移时不能只迁数值，要连状态字段一起迁。订单数据涉及支付流水号，迁移后要保证历史订单仍可查询和退款。

预约型小程序改版，旧数据核心是预约记录和时段配置。时段配置和日期强相关，迁移时要检查时区设置。旧版用 UTC 时间，新版用北京时间，不处理就会差 8 小时。

多端小程序改版，比如同时有微信和支付宝版本，数据可能分别存在两个后台。改版时要么合并到一个后台，要么保持双后台同步。合并时注意用户 ID 冲突，同一个手机号在两个平台可能生成两个不同账号。

处理方式：先跑迁移测试，再切换正式环境

不要直接在生产环境做迁移。先复制一份旧数据到测试环境，用迁移脚本跑一遍。跑完后抽查记录，看用户能不能登录，订单能不能打开，图片能不能显示。

迁移脚本要写回滚方案。如果导入一半失败，能恢复到迁移前状态。回滚不是删表重来，而是保留旧数据快照，新数据写入新表，切换时改配置指向。

切换时间选在业务低峰期。电商选凌晨，预约选工作日晚上。切换前发公告，告诉用户改版期间可能短暂无法使用。切换后安排人盯日志，看有没有报错和异常登录。

旧数据迁移完成后，不要马上删除旧库。保留至少一个完整业务周期，比如电商保留 30 天，预约保留 14 天。期间发现遗漏数据，还能从旧库补迁。

如果旧系统是第三方平台，先确认平台是否提供数据导出接口。没有接口就问客服要数据库备份。拿不到备份，只能手动导出 Excel，再写脚本清洗导入。这种方式容易丢字段，要逐列核对。

长沙小程序改版不是换一套皮肤。数据迁移方案定不下来，改版就不要开工。先让开发方出一份数据迁移清单，列出每张表的来源、去向、字段映射和测试结果。清单确认后，再排改版上线时间。