Managing Structure Licenses During Migration to Foundation

Plan for 30 to 60 days of overlap: run Structure and Foundation in parallel while teams validate Foundation against real workflows. The Atlassian Marketplace bills per-app per-user through Atlassian's own billing system, so both apps' fees stack during the overlap. Timing the Structure cancellation around your renewal cycle keeps the cost surgical and avoids leaving pre-paid money on the table.

Why run both apps in parallel during migration?

Migrations fail when the new tool becomes the only tool before the team has trust in it. The parallel-run pattern — keep Structure live while Foundation imports the same hierarchies alongside it — buys you a safety net that pays for itself in a single avoided rollback. Nothing in Jira changes during import. Both apps read the same underlying issues. The team can switch between them mid-sprint while muscle memory migrates from one UI to the other.

Thirty days of overlap is usually enough for a small team (under 25 users, under 1,000 issues) to validate that Foundation covers their day-to-day workflows. Sixty days is the right target for organizations with multiple portfolio owners, cross-functional reporting dependencies, or complex Structure generator configurations that need translation to Foundation Sync Agents. Ninety-day overlaps are rare and usually signal scope issues the migration itself will not solve.

Running both apps simultaneously costs real money — see Atlassian Marketplace licensing — but it is usually the cheapest insurance you can buy during a tool migration. A failed cutover that forces you to reinstall Structure and rebuild generator state costs far more than one or two extra months of license fees.

What does the 30/60/90 cutover pattern actually look like?

The 30/60/90 pattern anchors the migration to four calendar milestones rather than vague “when we feel ready” language. Map these to your own renewal date and the math writes itself.

Day	Milestone	Structure state	Foundation state	Billing state
Day 0	Foundation installed; initial import	Live, primary tool	Installed, imported, shadow mode	Both apps billed from Day 0
Day 30	Pilot team cutover	Still live for non-pilot teams	Primary for pilot team	Both apps billed (overlap month 1)
Day 60	Broad cutover — Foundation default	Read-only reference	Primary across the org	Both apps billed (overlap month 2)
Day 90	Structure uninstalled at renewal	Cancelled / uninstalled	Sole portfolio tool	Only Foundation billed

The shape is intentional. Day 0 through Day 30 is the validation phase: pilot team uses Foundation in earnest while the rest of the org stays on Structure. Day 30 through Day 60 is expansion: more teams cut over as confidence grows. Day 60 through Day 90 is the glide path — Structure is read-only, nobody is creating new structures in it, and you are running out the clock on the existing subscription. At Day 90 (or whenever your Structure renewal lands closest to Day 60), you uninstall Structure and billing collapses to a single line item.

How does Atlassian Marketplace billing work during the overlap?

Every paid app on the Atlassian Marketplace — Structure, Structure.Gantt, Foundation, any other PPM or utility tool — is billed independently through Atlassian's centralized Marketplace billing system. You do not pay Tempo directly for Structure; Atlassian invoices you for Structure and remits to Tempo. Same for Foundation, same for every other app. See the Marketplace buying and licensing documentation for the contractual specifics.

The practical consequence for migration: each app is its own subscription line, with its own per-user tier and its own renewal cadence. You cannot pause one while keeping the other active. You cannot have Atlassian bill them on a unified cycle unless both happen to renew on the same day. And you cannot transfer users from one app to the other — the user-count tiers are evaluated independently.

During the overlap, both invoices hit. If Structure is billed for 100 users and Foundation is billed for 100 users, you are paying for 200 user-licenses for that billing window. The good news is that Atlassian's user-tier brackets work in your favor on the way down: when Structure is cancelled and only Foundation remains, you drop straight to the Foundation-only bill with no wind-down ramp.

Annual vs monthly billing — how does each affect the timing?

Atlassian Marketplace subscriptions come in two cadences, and they behave very differently for migration timing. Atlassian's licensing documentation spells out the terms in detail.

Monthly billing cancels at the end of the current billing month. If you cancel on the 10th of the month, you keep service through the last day and are not charged for the next month. This is the friendliest cadence for migration because you can pull the license on relatively short notice without leaving pre-paid money behind. The downside is that monthly rates are almost always higher than annual per-user, so teams on monthly billing are already paying a premium.

Annual billing runs to the renewal date. If you paid for twelve months in January and cancel in June, you keep service through the following January with no refund — Atlassian does not pro-rate annual subscriptions on the Marketplace. This is the billing model where timing becomes mission-critical. Cancelling two months early costs you two months of service you already paid for. The correct play on annual is to complete cutover roughly 30 days before the renewal date, let the final month of Structure lapse as a read-only reference, and allow the subscription to terminate at renewal.

Mixed cadences are common: Structure on annual, Foundation on monthly during pilot. This works fine — just anchor your cutover calendar to the Structure renewal date (the less flexible of the two) and let Foundation's monthly cadence absorb the timing ambiguity.

When should you actually pull the Structure license?

The trigger for cancelling Structure should be a combination of calendar and criteria, not one or the other alone. Calendar prevents indefinite drift; criteria prevent premature cutover.

Calendar trigger: 14 days before your Structure renewal date. If you are on annual, this gives Atlassian's billing system time to process the cancellation and ensures the subscription will not auto-renew. If you are on monthly, it lets you ride out the final billing month as a read-only reference window.

Criteria triggers: all of these should be green before you pull the license. Every production portfolio view has a Foundation equivalent. Every Structure generator has a mapped Sync Agent or a documented reason for being retired. Every stakeholder who was using Structure has opened their Foundation Lens at least once and confirmed the data matches. The Gantt, views, and permission grants have been spot-checked. Any Expr formulas have been rebuilt as Sync Agents, saved views, or exported to CSV for archival reporting.

If the calendar trigger fires before the criteria are met, extend by one billing cycle. A month of double billing is cheap compared to cutting over with known gaps. For the narrative around this and broader cutover mechanics, see zero-downtime migration patterns for Jira PPM and the 10-minute variant at Structure to Foundation: the 10-minute migration guide.

What data do you lose when you uninstall Structure?

Very little that matters, if Foundation has already imported. A lot, if it has not. Uninstalling Structure removes Tempo's own data layer: the structure hierarchy definitions, generator configurations, Structure-only attributes (Expr formulas, custom computed columns), saved Structure views, historical baselines inside Structure, and permission grants scoped to Structure structures. None of this is Jira data — Jira issues and their links are untouched — but it is still the metadata that made Structure useful to you.

Foundation's Structure Cloud Import carries the hierarchy, generators (translated to Sync Agents), JQL-based configurations, saved views, and permission grants across before you uninstall. What it does not carry are Expr formula columns (Foundation's formula engine is on the post-MVP roadmap) and historical baselines. If either is load-bearing for your reporting, export them to CSV from Structure before you uninstall. The export is one-time and takes 10 to 15 minutes per structure; the data is yours to keep regardless of Marketplace state.

The uninstall itself is not destructive on the Jira side. The same is true if you reinstall Structure later — the app comes back empty, but your Jira issues are still where they were. This is the same property that makes parallel-run safe in the first place.

How do you handle SSO and user provisioning during the transition?

For almost every team, the answer is “do nothing.” Both Structure and Foundation inherit identity from Atlassian itself, so the SSO, MFA, and user-directory setup you already have on Jira is the SSO, MFA, and user-directory setup you get on both apps automatically. Atlassian's cloud migration guidance covers the identity layer in more depth, as does the Atlassian cloud migration support portal.

The edge case worth watching is group-based permissions. If your Structure permission model relies on custom Atlassian groups (e.g., a “Portfolio Admins” group that has elevated Structure rights), Foundation's permission UI needs the same groups for the equivalent grants. The groups already exist in Atlassian — you do not recreate them — but you do need to re-apply the grant against each Foundation Lens after import. Budget 10 to 20 minutes per Lens for permission review.

SCIM provisioning, if your organization uses it, is unaffected. Both apps derive their user visibility from Atlassian's user directory, which is what SCIM already populates. There is no separate provisioning endpoint, no second-source-of-truth problem, and no temporary accounts to clean up after cutover.

Where Foundation fits

Foundation is a Forge-native PPM app for Jira Cloud, billed through the same Atlassian Marketplace system as Structure. It undercuts Structure + Structure.Gantt on combined monthly cost at every tier, and the free edition (up to 10 users) lets you run the pilot phase of the 30/60/90 pattern at zero incremental cost while Structure billing continues as normal. For a head-to-head cost breakdown and migration context, see migrating from Structure to Foundation. For the deep-dive on the import tool itself, see the Foundation migration overview.

How we sourced this guidance

The timing pattern on this page reflects four Structure-to-Foundation migrations we supported between late 2025 and March 2026. Team sizes ranged from 12 to 180 users; three were on Structure annual billing, one was monthly; two also held Structure.Gantt subscriptions. Every team chose an overlap of 30 or 60 days. None of them lost pre-paid Structure time. None of them experienced a failed cutover that required rollback. The 30/60/90 milestone table is derived from the average of those four calendars, rounded to easily-remembered multiples of 30. Pricing, billing-cadence, and cancellation-policy claims in this guide are drawn from the Atlassian Marketplace licensing terms as published in April 2026; verify against your specific contract and billing cycle before making commitments.

Frequently asked questions

Can Structure and Foundation run on the same Jira site at the same time?

Yes. The Atlassian Marketplace allows any number of apps to be installed on a single Jira Cloud site simultaneously. Structure and Foundation each maintain their own data stores (Structure on Tempo's servers, Foundation inside Atlassian Forge), so they do not conflict at the infrastructure layer. Both apps read from the same underlying Jira issues, so the same issue can appear in a Structure structure and a Foundation Lens at the same time, and edits flow back to Jira either way.

Do I pay double during the parallel-run window?

Yes, for the overlap period. Atlassian Marketplace licensing is per-app, per-user — each app's fee is billed independently through Atlassian's billing system. While both apps are installed and active, both invoices continue. This is the expected cost of a safe migration. Most teams treat it as one to two months of overlap expense in exchange for zero-downtime cutover confidence. Budget for 30 to 60 days of double billing and time the Structure cancellation against the renewal date to avoid leaving pre-paid money on the table.

How do I cancel Structure without losing pre-paid time?

Atlassian Marketplace apps on monthly billing cancel at the end of the current billing month, and annual subscriptions run to their renewal date. Neither is pro-rated mid-cycle. The pattern that works best is: confirm your Structure renewal date in Atlassian billing, plan your cutover for roughly 30 days before that date, complete validation, and let the Structure subscription lapse at renewal rather than actively cancelling partway through. You finish using something you already paid for, and Foundation's first month of sole usage overlaps the end of Structure's pre-paid period by design.

What about Structure.Gantt — is that a separate license too?

Yes. Tempo sells Structure.Gantt (the Gantt extension for Structure) as a separate Marketplace app with its own per-user subscription. If your team runs Structure plus Structure.Gantt, you are managing two Tempo subscriptions, stacked on top of each other. Foundation Advanced includes a built-in Gantt with the same core capabilities, so the post-migration bill usually drops not by one line item but by two. When comparing monthly cost, make sure you are totalling both Structure and Structure.Gantt on the incumbent side.

Does uninstalling Structure delete my Jira data?

No. The source-of-truth data — Jira issues, issue links, sprints, custom field values — lives in Jira and is unaffected by any Marketplace app install or uninstall. What you lose when you uninstall Structure is Structure-specific metadata: the structure hierarchies themselves, generator definitions, Expr formula columns, saved Structure views, and any baselines Structure has accumulated. Foundation imports most of this before cutover. Export anything you cannot migrate (notably historical baselines and Expr formulas) to CSV before you uninstall.

Can my SSO and user provisioning stay the same during migration?

Yes. Foundation is a Forge app, which means it inherits your existing Atlassian identity and access management automatically. If your users already sign into Jira via SSO (Atlassian Access, Okta, Azure AD, Google Workspace), Foundation uses the same login with no additional configuration. There is no separate user directory to provision, no new passwords, and no extra SCIM endpoint. Structure, as a Connect app, behaves similarly for SSO purposes — so users experience the parallel-run period as two apps sharing a single login, not two separate authentication flows.