Migration blocker: legacy public app → developer projects fails with installation limit (65+ install

Developer Support
,
1

Hi everyone,

We’re migrating a legacy HubSpot public app from legacy CRM cards to UI Extensions (app cards / developer projects), and we’re stuck on what feels like a circular dependency. Would appreciate any guidance from others who’ve been through this.

Our setup

We have three related apps:

  1. Labra QA (legacy) — App ID 1071826

    • Internal QA app
    • Still on legacy CRM cards
    • ~12 installs (all internal test accounts)

  2. Labra Production (legacy)

    • Customer-facing app
    • Legacy CRM cards
    • 65+ active customer installs

  3. Labra App Card (new)

    • Separate developer project under a different app ID
    • Built with UI Extensions / app cards
    • Not yet rolled out to existing customers

The blocker

When we run the migrate command on the legacy QA app (1071826), we get an installation limit error and migration stops.

From the docs we’ve read, migrating a public app with multiple installs may require Marketplace listing — but Marketplace review feedback says:

  • Legacy CRM cards are not allowed for listed apps
  • We must migrate to app extensions first
  • Listing must map to one app ID only (the app customers actually install)

So we’re in a loop:

  • :cross_mark: Can’t migrate because of install limit error
  • :cross_mark: Can’t list legacy app until it uses app cards
  • :cross_mark: Can’t use a new app ID for listing and switch later
  • :cross_mark: Can’t uninstall 65+ production customer installs to bypass the limit

What we’re trying to figure out

  1. What is the correct migration path for a legacy public app with many existing installs?
  2. Can migration be enabled without Marketplace listing?
  3. Should we migrate in place on the same app ID instead of keeping a separate app card project?
  4. How do others handle customer continuity during this transition?

What we’ve already tried

  • Built app cards in a separate developer project (new app ID)
  • Attempted hs project migrate (or equivalent migrate flow) on legacy QA app → installation limit error
  • Reviewed “Migrate a public app to the developer projects framework” docs
  • Received Marketplace feedback that listing must match the actual installed app

If anyone from HubSpot or the community has solved this for a production app with existing installs, we’d really appreciate pointers, docs, or the right team to contact.

Thanks in advance!

— Durvankur, Labra

3

Hi @oppsync-admin,

Welcome to the community!

Thanks for clearly explaining your situation here! This is a nuanced migration scenario and we appreciate the helpful context.

The install limit error combined with Marketplace requirements does create a tricky sequence-of-operations problem. A few resources that might help while you wait for community input:

Tagging some of our top contributors in the developer space who may have run into this.

Hey @evaldas, @MichaelMa, @Anton – do you have any suggestions for @oppsync-admin on this?

Thanks!

Sam, Community Manager

4

Hi @oppsync-admin, I would avoid treating the new app ID as the future Marketplace app unless HubSpot explicitly confirms customer continuity can be transferred. Existing installs, scopes, CRM cards, webhooks, and review history are all tied to app identity, so same-app-ID migration is the safer model.

Practical path:

  1. Keep production customers on the legacy public app while you test the developer project in an internal QA app.
  2. Ask HubSpot Developer Support/Marketplace for an install-limit migration unlock or guided migration path on the production app ID. Include install count, listing feedback, exact CLI command/error, and whether the QA app can migrate.
  3. Do not uninstall customers just to get under the limit; that creates OAuth churn and breaks continuity.
  4. Once HubSpot unlocks the path, migrate the installed production app in place, then submit/update the listing against that same app.

The strongest evidence to share is: same app ID required for listing/customer continuity, migration blocked by install count, and a separate app ID already proving the new UI extension works.