Tuya OEM to SDK Migration: What Actually Carries Over

By the Vesetail team - we work exclusively on custom Tuya App SDK and Cloud API builds for product companies.

Updated July 14, 2026. Migration guidance should always be confirmed against your own Tuya project, app schema, store assets, and real user accounts.

Moving from a Tuya OEM App to a custom App SDK build is not a code conversion. A standard Tuya OEM App does not provide a source-code migration path; the SDK app is a new application implementation built against the underlying Tuya products, accounts, and cloud configuration. What can carry over is that underlying system - and how much of it carries over depends on which migration path you are actually on.

One question comes before all of this: whether the limitations of the current OEM App are already affecting product value, support cost, or the next stage of the roadmap. If the OEM template still covers your needs, or the product is still in validation with a small user base, migration can wait - the right question is never whether an SDK app offers more control in the abstract. We cover that decision separately in Tuya OEM App or Tuya App SDK? How to choose. This article is for teams that have made the call and now need to know what survives the move.

First, identify your migration path

Store continuity and data continuity are separate questions. Whether you can publish on the existing store listing depends on developer-account access and signing assets; whether existing users keep their accounts and devices depends on the schema and account configuration. The two answers combine into four distinct project types.

If store continuity and account continuity are both confirmed, the project may qualify for an in-place replacement - and a validation build should prove that before the rollout plan is finalized.

Note what is not in this table: how many regions your users are spread across. Data-center distribution does not define the migration path on its own, but it can split one rollout into several regional validation and transition plans. Current market coverage alone does not tell you where a years-old user base is actually stored.

What can carry over - and what must be rebuilt

A live Tuya app is several systems stacked together: a store identity, an account base, homes and sharing relationships, paired devices, product definitions, scenes, and the app experience itself. These layers do not move together, which is why “seamless migration” claims and “complete rebuild” warnings are both wrong - each layer has its own answer.

The most durable layer is the device-product layer. The device firmware and DP definitions do not disappear when the mobile app changes - but each required capability still needs to be supported and exposed correctly in the SDK app.

The least durable layer is the experience. Navigation, onboarding, pairing flows, device-control screens, failure states, push notifications, and support journeys all have to be implemented in the SDK app. That is not a reason to redesign everything: the initial migration release should change what creates product value or reduces support tickets, and deliberately keep the device hierarchy, naming, and core control behavior that existing customers already understand.

Everything between those two layers is where migrations succeed or fail. It comes down to three continuity questions.

Three continuity questions to validate

1. Store and release continuity

On Android, an update must keep the existing package name and a valid signing relationship; on iOS, the bundle ID ties the app to its App ID and provisioning setup. A technically perfect SDK build cannot ship as an update if the team cannot produce the developer-account access and signing keys behind the current listing - which is worth verifying early, especially after a change of development vendor.

Tuya authenticates Android app signatures against a signature allowlist. When Google Play App Signing re-signs the build, the Play-generated SHA-256 certificate fingerprint must be added to the app configuration on the Tuya Developer Platform before store review and production validation. Otherwise, internal builds may work while the published build rejects logins.

Store identity is also not the last gate. Even after device control works, launch can still be blocked by several external dependencies:

• Third-party login configuration (Google, Apple, Facebook)
• Push-notification certificates and tokens
• Cloud video and other paid value-added services
• Existing panels and MiniApp dependencies
• Privacy consent and account-deletion requirements
• Analytics, crash reporting, and support tooling

These belong in the migration scope from the start, not in a post-launch punch list.

2. Account and regional continuity

Tuya’s support documentation defines the app schema as the unique identifier of an app - the value that cloud APIs require to register and query that app’s users. It appears in the details page of the existing OEM App or App SDK on the Tuya Developer Platform as the channel identifier.

A new SDK app receives its own app record and keys, and Tuya’s public documentation does not establish a universal rule that it can share an existing OEM App’s schema and inherit its users. That must be confirmed with Tuya through a support ticket or account manager before development begins. Even where the schema checks out, account, home, sharing, and device continuity still need to be proven with real accounts.

Regional distribution multiplies that proof. Tuya allocates accounts to data centers based on the country code used at registration, and its documentation is explicit that data in different data centers is isolated. Mappings can also change while historical accounts remain in their original centers. For a product sold across several markets over several years, one successful test account proves very little; the validation plan needs representative accounts from each market actually served.

The account model determines what the login screen must implement. The SmartLife App SDK supports phone, email, and third-party login, plus UID login for brands with their own identity system - Tuya describes the UID as the unique user identifier in your system, used to bind your database to Tuya’s. The SDK app must either preserve the current account path or implement a deliberate transition to a new one, such as binding users to a brand account system through UID login. Reproducing the old login screen is not enough either way: the underlying identifiers, region, and account relationship must still reach the intended user records.

And one scenario is settled by documentation rather than validation: if your customers use the Smart Life app rather than a brand-owned OEM App, Tuya states plainly that the Tuya app, Smart Life app, and OEM apps are separate account systems that cannot log in to each other, even with identical credentials. That is the fourth path in the table above - a user acquisition and device onboarding project, not a migration.

3. Product and device continuity

This is usually the strongest layer, and still not automatic. Confirm who owns the Tuya products, which cloud project they belong to, which applications are authorized, and whether all required PIDs - including gateway and sub-device relationships - are available to the new app. Standard Tuya panels and category services can carry additional dependencies of their own, and the Cloud API services, project permissions, device authorizations, and event subscriptions used by the backend must be reviewed and reauthorized for the target configuration - they do not move by themselves, and API rate limits and token management in the target cloud project deserve the same check.

Validate before you build

The safest structure is not a full build followed by a launch date. It is a short chain of proofs, each cheap enough to fail.

Start with a continuity audit: document the current app’s schema, account model, user regions, products, store assets, and platform dependencies, and mark each as expected to continue, needs validation, must be rebuilt, or deferred beyond the migration release. Most teams can fill in the product and store items from memory; the schema, regional, and account-model items usually need the Tuya ticket described above.

Then build the smallest thing that can prove continuity: a validation shell that authenticates real existing accounts, lists their expected homes and devices, reads device status, sends core commands, and exercises sharing roles - in each target region. The same shell should also test one new-account registration and new-device pairing path in every priority region, because preserving existing users does not prove that future onboarding will work. This build is worth more than any amount of UI design done before the data relationship is confirmed.

Ship a continuity-first migration release

Once continuity is proven, the initial migration release should protect it: user continuity first, core device control second, support risk third, and a limited set of high-value improvements last - the things the OEM template could not express. Roadmap ideas stay out unless launch depends on them.

Then roll out in rings: internal accounts first, then a selected customer group or single market, watching login failures, missing devices, unexpected re-pairing prompts, and support tickets. For projects on the new-listing or account-transition paths, define the old-app support window, the fallback path, and device re-pairing instructions before the first customer group is moved. Only then the full base - with update instructions, login-recovery guidance, support scripts, and a plan for the users who will not update for months. A migration is half a software project and half a customer-transition project, and the second half is the one that generates the support tickets.

FAQ: Tuya OEM-to-SDK migration

Can users keep their existing Tuya OEM App accounts?

Sometimes. Tuya must confirm whether the SDK app can reach the required schema and data relationship, and the result still needs to be validated with representative real accounts.

Will users need to re-pair their devices?

Not necessarily. Re-pairing is required only when the new app cannot reach the correct user, home, and device relationships. Product access alone does not prove that every existing device will appear for every user - that is what the validation build is for.

Can the SDK app replace the OEM App in the same store listing?

Often, provided the brand controls the developer accounts, bundle or package identity, signing assets, and required Tuya signature configuration before store review and production validation.

Do homes, scenes, and sharing relationships carry over?

They may, but test them separately. Loading a device does not confirm that every member role, room assignment, or automation behaves correctly. Test the scene types your customers actually use.

Do we still pay Tuya after moving to an SDK app?

Yes, for commercial use. Tuya’s Official Edition is currently published at USD 5,000 for the initial annual subscription and USD 2,000 for subsequent annual renewals; the free development edition covers development and limited testing only. Pricing may change, so confirm the current terms before finalizing the migration budget - see our Tuya OEM App pricing vs SDK app cost breakdown for the full picture.

Is this a complete rebuild?

The mobile experience is a new build. The products, device functions, store assets, and - after validation - the account and device relationships underneath it are not.

Migration Readiness Review

Share your current OEM App setup, user model, device categories, active markets, and rollout goal. Start with a migration-readiness review covering:

• What can likely carry over
• What Tuya must confirm
• What needs a validation build
• What belongs in the initial migration scope

The initial review is a free 30-minute call. Write to sales@vesetail.com with a short description of your current app and devices, and we will come back with times.

Official Tuya references

• What is the app schema and where can I get it?
• Mappings Between OEM App Accounts and Data Centers
• User Account Management (Smart App SDK)
• What is the account system?
• Enable Signature Protection for Android
• SmartLife App SDK Pricing
• Login with UID

Project-specific OEM-to-SDK account continuity is not established by public documentation. It should be confirmed with Tuya for your project and proven through a validation build.