There is no account migration: moving members to a new entity's mini program

The old mini program cannot be transferred. Not renamed, not redirected, not migrated into the new one. WeChat's account migration process exists, but its eligibility rules exclude overseas-entity accounts. When the business moves to a different entity, the new entity starts with a new mini program, a new AppID, and a new namespace. The members are still on the old one.

That changes the shape of the project. A cross-entity migration is not an import that moves rows from one database to another. It is a re-linking process: each member has to establish a new identity on the new app, and the assets follow only after that.

1. Accept what the platform will not do

Two WeChat capabilities are often confused. Account migration moves users from one mini program to another: the AppID changes, the old app is deregistered, and users who open it are redirected to the new one. Entity change happens inside one account: the AppID stays the same and the operating entity changes. They are different operations with different requirements.

For this project, the important line is in the account migration eligibility rules: overseas-entity accounts are not eligible. Different entities therefore have no platform-level migration path. The new entity registers a new mini program; the old one is not deregistered or redirected. OpenIDs belong to the old namespace, and a UnionID is only shared when both mini programs are bound to the same WeChat Open Platform account — a condition a cross-entity move usually does not meet.

Plan for re-acquisition and re-linking, not for a platform switch.

2. Define “migrated” for one member

“Migrated” is not a row count. For each member, three things have to happen: they are told what is changing, they link their old identity to a new account, and their assets are credited under an approved rule. A member who has been notified but not linked has not migrated. A balance credited to an unmatched record has not migrated either.

Classify the population before designing the flow:

• Linkable with evidence. A member card, order number, verified email, or login to the old system proves control of the old account.
• Linkable only with help. The person exists but cannot self-serve; customer service or an in-store check is needed.
• Conflicting. Two records point at the same person, or one person has several accounts. Do not merge automatically.
• Unmatched. No usable identifier. Keep them visible and give them a claim path.

Define success per class. “90% linked” is meaningless if the remaining 10% hold the largest balances.

3. Build the re-linking flow before the import

Start from the identifiers you actually have. An old member card number plus a name, an order number from the old app, a verified email, or a login to the old system can each serve as proof. A one-time code sent to the member's email, or a manual check by customer service, gives you a fallback when self-service fails.

Do not make the phone number the only path. For most overseas-entity mini programs it is unavailable, and even where it exists it may be outdated or shared. Offer at least two ways to link, and make the fallback visible on the page rather than hidden behind support.

Test the flow with real members before the asset import. Measure completion, where people drop off, how many need help, and how long a support case takes. Those numbers decide the batch size and the support plan, not the other way around.

4. Use the old app as the announcement channel

Because there is no automatic redirect, the old mini program is your best communication surface while it is still running: a home banner, an order-page notice, a customer-service message, a QR code to the new app, and a clear deadline. Add the same message to the channels members already use — official account posts, email, messaging apps, and offline materials.

Be specific about the official channel and the new app's name. A migration notice is also a phishing opportunity; tell members that staff will never ask for a password or a verification code, and never collect payment through a personal account.

Keep the old app alive through the transition. Closing it before the link rate stabilises turns a difficult migration into an outage.

5. Move assets after the link, not before

Once a member is linked, credit the assets under rules agreed in advance. Treat points, tiers, coupons, and stored value separately; they have different logic, different owners, and different failure modes. A single conversion rate cannot cover all four.

Reconcile each asset before and after the batch, and give the member a statement they can check: what was recognised, what was credited, what expired, and how to dispute it. A silent credit is almost as bad as a missing one.

6. Pilot, then batches

Run the first batch on 100–500 members, deliberately including the messy cases: changed emails, duplicate accounts, negative balances, and people who need help. Measure the link rate, the support load, the exception types, and the time per case.

Agree the acceptance criteria before the pilot: which variance is tolerated, which must be zero, who signs off, and what the rollback or compensation path is. Then increase the batch size. A migration that works for clean records and fails on exceptions has not been tested.

7. Tell the member what actually changes

Members do not read migration plans. They read one message and look at one balance. Say what stays, what moves, what expires, when the old app stops, how to claim, and where to complain. If the member has to act, say so plainly; do not promise a seamless experience that the platform cannot deliver.

Prepare the customer-service script before launch, not after the first complaint. The script should answer the three questions that will dominate: “Is this official?”, “Where did my balance go?”, and “What if I cannot log in?”

8. The sequence on one page

1. Confirm the entity and app plan: new entity, new mini program, new AppID.
2. Inventory identifiers and assets; count what has no usable identifier.
3. Choose at least two re-linking methods, including a manual fallback.
4. Build and test the claim flow with real members.
5. Prepare old-app announcements, official-channel messaging, and support scripts.
6. Run a 100–500 member pilot with the messy cases included.
7. Reconcile assets per type; agree who owns every variance.
8. Cut over in batches, keep a grace period, and audit the result.

None of this makes the migration invisible. It makes it honest: the members who can be linked are linked, the assets that can be reconciled are credited, and the rest has a name and an owner.

AcrossFlow works through this sequence with merchants planning a cross-entity move. If you are planning one, start with the identifier inventory and the re-linking flow, not the import button.