Legacy Public App vs Projects App

A legacy public app and a Projects-based app are not just two labels for the same workflow. The May/June 2026 changelog is about the ability to create new legacy public apps through the legacy Developer Platform UI. The Projects-based developer platform uses CLI and file-based project configuration for new app development.

This distinction matters because stakeholders often compress the announcement into a vague deadline. The safe planning statement is narrower: new legacy public app creation is being disabled; existing legacy public apps continue functioning under that specific sunset.

When you explain this to a client or internal team, separate three questions: Do we need a new public app? Do we need to modernize an existing app? Do we have a separate Marketplace or CRM card deadline?

Legacy UI creation is the path being sunset for new public apps. If a team was planning to create a new public app from the old UI, they should shift their planning to the Projects-based CLI app creation flow.

For existing legacy public apps, the right next step is usually inventory and risk review, not panic migration language. Document installs, OAuth behavior, scopes, webhooks, CRM cards, Marketplace status, and any modernization timeline before assigning a command path.

If the existing app is not project-based and modernization is desired, review the public app migration docs and `hs app migrate` guidance. Do not assume a new-app creation flow is the same as migrating an existing app.

Projects-based apps use file-based configuration and HubSpot CLI workflows. That makes the project easier to review in source control, pass through CI checks, and hand off between developers compared with an undocumented UI-only process.

The main planning artifacts are the project files, platform version, app schema/config files, auth configuration, and the commands used for creation, upload, local development, and migration. Those artifacts should be reviewed together instead of scattered across chat notes.

A good handoff ends with the likely path to verify, relevant official source links, and open questions. It should not end with a guaranteed command, because the correct path depends on app type, project state, platform version, and current official docs.