An OpenID is not a customer ID

Imagine the export looks complete. Tens of thousands of rows. A member ID, a phone number, a points balance, a tier, a join date. The file finishes cleanly. The new platform says it can import a CSV. It feels like the hard part is over.

Then someone asks the only question that matters: when a returning customer opens the new mini-program, which row is this person?

For an overseas-entity mini-program, there is usually a second gap before you get that far: most cannot obtain member phone numbers at all. The identity path has to be designed as if the phone number is unavailable.

If the answer is "the one with their OpenID", the migration is not ready. An OpenID is an identifier, but it is not a customer identifier in the sense most migration plans assume. It is a receipt from one specific app. It does not travel.

What an OpenID actually identifies

WeChat issues an OpenID per app. The same WeChat user who opens mini-program A and mini-program B receives two different OpenIDs; WeChat's terminology guide is explicit about this. The value is stable inside A; it is not a global key to the person. This is by design: it limits what one app can learn about a user's activity in another.

UnionID is the exception that makes cross-app matching possible — but only inside one WeChat Open Platform account. If both apps belong to the same Open Platform entity, the same user can share a UnionID across them. That is a meaningful link. It also depends on account structure, binding, and platform rules, not on the export file. It is not a universal customer ID, and it is not something you can assume survives a move to a different entity. The UnionID mechanism is worth reading before you rely on it.

LINE works on the same principle with different nouns. LINE's documentation says user IDs are issued per provider: the same LINE user gets a different user ID under a different provider. Within one provider, the ID is the same across channel types, such as a Messaging API channel and a LINE Login channel. Move to a new provider and the old ID no longer resolves.

The pattern is consistent: the platform is the authority that maps a person to an ID, and it only does so inside its own boundary. Your export contains the result of that mapping, not a copy of the mapping itself.

Why the new platform cannot simply look it up

A new platform generally has no API that accepts an OpenID from another system and returns a customer. It has its own namespace and its own users. Even when two apps are technically related, the lookup depends on permissions, account ownership, and whether the user has ever interacted with the new app.

For overseas-entity mini programs, one option is removed entirely. WeChat's account migration eligibility rules exclude overseas-entity accounts, and entity change does not apply across different entities. A move to a different entity therefore means registering a new mini program, not transferring the old one. The old app will not redirect users automatically, and no identifier carries over. The practical sequence is covered in a separate note on cross-entity moves.

There are four common failure points:

• Namespace mismatch. The target app issues a new identifier for the same person. The old value is just a string it cannot resolve.
• No shared authority. The old and new platforms are operated by different entities, or are not bound to the same developer account, so there is no platform-level link to follow.
• The user has not arrived yet. Matching only becomes possible when the person opens the new app and authenticates. A batch import cannot invent that event.
• Privacy and permission limits. Platforms restrict how identifiers can be used, shared, or queried. A path that looks technically possible may still be contractually or legally unavailable.

This is why "we have the OpenIDs" is not a migration plan. It is an inventory of strings whose meaning is owned by the source platform.

What can actually match a person

Matching methods are not equal. Treat them as a hierarchy, and record the confidence level in the output:

• User-mediated linking (highest confidence). The customer signs in on the new platform and proves control of the old account: a one-time code sent to a verified phone or email, a login to the old system, or an explicit consent step. This creates a new, legitimate link. It is slower, but it is the only method that works across unrelated platforms without guessing.
• A verified attribute you already own. A phone number or email that was verified in the old system can be matched to the same verified attribute in the new one, provided you can obtain it. The key word is verified. An unverified, manually typed number is a hint, not an identity; shared family numbers make it weaker still.
• A platform-level link. A UnionID under the same Open Platform account, or an equivalent provider-level identifier that both systems can legitimately resolve. This is strong, but only while the account structure and platform rules hold.
• Probable matches (never auto-merge). Same normalised phone, same email with a plus-address, same name and address, similar order history. These can reduce manual review, but they must be labelled probable and reviewed before any asset moves.
• Unmatched or conflicting. No reliable attribute, or two records pointing at different people. Keep them visible. Do not let a fuzzy score silently merge a balance.

One availability caveat belongs here. WeChat's phone number verification component is not open to every mini program: mainland entities can generally use it, but for most overseas entities it is unavailable. The current announcement describes a limited gray beta only for certain countries and regions: Hong Kong, Macau, Taiwan, Japan, South Korea, Singapore, Malaysia, Thailand, Vietnam, Cambodia, Myanmar, Indonesia, Laos, the Philippines, New Zealand, Australia, and the UAE. For most overseas-entity mini-programs the phone-number path does not exist, and a migration plan that assumes it does is built on a field you cannot obtain. Design the identity path without it, and treat phone matching as a bonus if it happens to be available. Check the current scope before scoping identity matching.

The output of a readiness assessment should be a count by class, not a single match rate. "92% matched" hides the other 8% and says nothing about whether the 92% were matched correctly.

The part that is not a data problem

Even a perfect match is not automatically a permitted migration. The customer may need to be told what is moving, why, and who will hold the data afterwards. Some flows require fresh consent before the new platform can contact the person. Stored value may be treated as a financial liability with its own rules. A plan that begins with a CSV import and ends with a points balance often skips these steps entirely.

Write them down before the test batch: who is the data controller for the old and new systems, what is the legal basis for the transfer, what notice does the customer receive, how can they object, and how long is the data retained. If those answers are missing, the technical match is not the bottleneck.

A small test you can run before committing

You do not need a full migration to learn whether the identity path works. Take a representative sample — 100 to 500 records, including the messy ones — and answer these questions with evidence:

1. What stable attribute exists today? Count how many records have a verified phone, a verified email, a platform-level link, or none of the above. Do not estimate from the schema; query the data.
2. Does the target accept it? Confirm the exact field, format, uniqueness rule, and API or import behaviour on the new platform. "It should work" is not confirmation.
3. What happens when the person arrives? Test the sign-in or linking flow end to end. Does it find the imported record? Does it create a duplicate? What does the customer see?
4. Can you classify the sample? Produce exact, probable, unmatched, and conflict counts. Review a handful of each with a human.
5. Who resolves exceptions? Name the owner, the channel, and the turnaround time. An exception queue without an owner is just a longer outage.
6. What is the fallback? Decide in advance whether unmatched members keep a claim path, receive a manual credit, or are contacted. Never leave a balance in limbo.

If the sample cannot be classified, the production migration cannot be estimated. That is a useful answer to have before a contract, not after one.

What good looks like

A controlled migration produces more than a completed import. It produces evidence: row counts at every stage, match classes with the rules that produced them, per-asset reconciliation totals, a list of exceptions with owners, and an audit trail of who approved what. Ambiguous identities stay separate. The merchant signs off on the reconciliation before the old system is switched off.

None of that requires promising that every record will move. It requires being honest about which records can be proven, which need the customer to act, and which cannot be resolved with the access you have.

The question to ask first

Not "can we export it?" but "can the new system recognise the person?" If the answer depends on an ID that belongs to the old platform, the migration is not ready. If it depends on a verified attribute you can actually obtain, a legitimate platform link, or a customer who will re-consent, you have something you can test — and a real basis for a scope, a budget, and a promise you can keep.

AcrossFlow is working with merchants facing this exact transition. If you are planning one, start with the identity inventory, not the import button.