Skip to content
JetStack AI Documentation

Legacy Projects

Projects was rebuilt from the ground up: the phase-based wizard (context gathering → blueprint approval → generation → deployment) was replaced by the durable workspace documented in the rest of this section — the Canvas, Project Knowledge, the versioned Blueprint, and Releases.

If you created projects in the earlier version, this page is the honest, complete account of what that means for them.

What Is Preserved

Section titled “What Is Preserved”
  • Your project still opens. Legacy projects appear in the portfolio and open in the new workspace. Nothing is deleted, archived, or locked read-only.
  • Everything you deployed to HubSpot is untouched. Assets created by old deployments still exist in the client’s portal, exactly as they were. The redesign changes how JetStack AI tracks work; it never reaches into HubSpot to remove or alter anything.
  • Your uploaded documents are still there. The files you added during the old context-gathering phase remain in the project and do not need re-uploading.
  • Nothing is retro-billed. AI usage from before AI credits existed stays on the house; credits apply only to new activity.

What Does Not Carry Over

Section titled “What Does Not Carry Over”
  • Deployment history and standing. The new model tracks every applied asset as a verified, per-asset record inside a Release. Old deployments predate that record, so previously deployed assets are not shown as live deployment bindings — they exist in HubSpot, but the project does not claim them. Old delivery history does not appear in any Release’s History tab.
  • The old context summary. Earlier projects have an AI-written context summary with no source-level citations. The new model only trusts source-backed knowledge, so that summary is hidden, not deleted — the workspace will not present unattributable context as fact, and Jetty will not design from it.
  • The approval-gated blueprint flow. There is no “Approve Blueprint” step anymore. An old project’s blueprint state is readable, but new design work flows through the versioned Blueprint derived from Project Knowledge.

Legacy Projects Are Production-Only at First

Section titled “Legacy Projects Are Production-Only at First”

The new model binds up to two portals per project — sandbox and production. Old projects predate that and have a single connected portal.

That single portal is treated as the project’s production portal, deliberately: mistaking a live client portal for a sandbox would apply sandbox-grade confirmations to production, and that is the expensive direction to be wrong in. The reverse costs you one extra confirmation dialog.

Practically:

  • The mode switch offers only Production until you bind a sandbox in the project’s Settings.
  • If the project’s portal has since been explicitly bound as a sandbox elsewhere, the project honestly reports that no production portal is connected rather than guessing.

Bringing an Old Project Into the New Model

Section titled “Bringing an Old Project Into the New Model”

Three steps take a legacy project to full parity with a new one:

  1. Re-analyze your documents. On the project’s home, the hidden-context notice offers to re-analyze the saved documents — no re-upload needed. This publishes a trusted, cited Project Knowledge brief from the same material, and the Blueprint derives from it.
  2. Run the portal scan. Trigger a scan from the Canvas so the project builds its live portal inventory — both the API lane and the browser lane via the Chrome extension. This is also how the project “sees” the assets your old deployments created: they show up in the Canvas like every other asset in the portal.
  3. Bind a sandbox (optional). If the client has a sandbox portal, connect it in Settings to unlock sandbox mode and the sandbox-first delivery rhythm.

From there, new work is normal work: scope a Release, authorize it, apply it, verify it.

If a New Release Touches an Old Asset

Section titled “If a New Release Touches an Old Asset”

Because old deployments are not tracked as bindings, a Release that generates an asset with the same name as one your old project deployed will treat the portal-side asset as existing portal content, like anything else already in the client’s portal. Review the Release’s plan in the Changes tab — it distinguishes creating new assets from updating existing ones — before authorizing. If you end up with an unwanted duplicate, delete it in HubSpot; the old asset was never under the project’s management to begin with.

Questions

Section titled “Questions”

Will legacy projects stop working at some date? No sunset is scheduled. Legacy projects stay openable, and the steps above are available whenever you choose to take them.

Can I get my old delivery history back? No — it was recorded in a model that no longer exists. The old assets’ current, real state is visible in the Canvas after a scan, which for delivery purposes is more truthful than the old status labels were.

Do I need to do anything if I never used the old Projects? No. This page only concerns projects created before the redesign.

Anything unclear about a specific legacy project? Contact hello@jetstack.ai with the project ID and we will look at its exact state.

Next Steps

Section titled “Next Steps”