Operations

Store Migration

Moving a store to a different operator, entity or technical environment while keeping the account and its history intact.

Aliases: Account migration, store transfer, 店铺迁移, 账号迁移

The three kinds of migration

Operator migration. The store stays with the same legal entity but moves to a different team or agency. The platform cares little, the internal controls care a lot: credentials, environment assignment and payout visibility all change hands.

Entity migration. Ownership or the operating company changes. Platforms treat this as a material change and require a transfer process, often with re-verification of the new entity. Several marketplaces prohibit transferring accounts outright.

Environment migration. The store moves to a new browser profile, a new network exit or a new device. Multi-account browsers such as Feikua Browser let the operator create that profile with its own proxy and fingerprint settings, which makes the handover repeatable rather than improvised. Technically simple, but it changes the signals the platform has learned, which is why it should be done once and cleanly rather than repeatedly.

What has to move with the store

Credentials and two-factor authentication devices
The environment: profile, proxy assignment, saved settings
Payout and tax records, if the entity changes
Product data, certificates and the compliance evidence pack
Communication history and open cases

Risks

The main risk is association. A new environment created inside a browser that already hosts other stores, or a proxy reused from another account, produces the overlap that account association checks look for. The migration has to start with a clean profile and an unused exit.

The second risk is verification. Entity changes trigger re-verification under seller verification rules, and a mismatch between the new registered name and the retained bank account freezes payouts.

The third is continuity: a migration that leaves the old environment active for a few weeks creates two environments for one store, which looks like two operators.

A sequence that works

Confirm that the platform permits the change, in writing where possible
Prepare the new entity documents and the new payout account
Create the new environment with its own profile and unused proxy
Migrate credentials and two-factor devices, then verify login from the new environment
Retire the old environment, and record the date
Update the store register and the role assignments

Relationship to the surrounding structure

Migration is an event inside multi-store management. It depends on environment isolation to keep the new setup clean, and on team access control to revoke the previous operators completely.

Primary source: Platform account ownership and transfer policies, reviewed per platform.

FAQ

Can a store be transferred to another company?

Only where the platform allows it. Several marketplaces treat account transfer as prohibited and require a new account for a new entity, so the policy should be checked before any commercial agreement.

Does migration trigger re-verification?

A change of entity, address or bank account usually does. Expect document uploads and a payout hold while the review completes.

How do I avoid association during migration?

Use a fresh browser profile and an unused network exit, and retire the old environment once the new one is confirmed. Do not reuse a profile that has hosted other stores.

What should be documented?

The date of migration, the new environment identifier, the entity documents, the credential handover and the revocation of previous access. Keep it with the store's compliance file.

Can I keep the old environment active as a backup?

Not for day-to-day access. Two active environments for one store create conflicting signals and duplicate logins, which is worse than a single clean environment.