Migrate from Structure to Foundation: The 2026 Guide

Foundation's Structure Cloud Import tool migrates your hierarchies, generators, and attributes in under 20 minutes. Your Structure licenses stay active through cutover, so you run both tools in parallel with zero downtime. Here is exactly what migrates, what doesn't, and the six-step process — tested end-to-end on a 500-issue structure with three generators and five custom attributes.

Why teams migrate from Structure to Foundation

The conversations we hear from teams evaluating a switch fall into four buckets, roughly in this order of frequency. Price. Per Tempo's public pricing pages and multiple Atlassian Community threads, Structure has raised prices three times in 18 months, with some tiers jumping more than 30%. Teams that priced out Structure at 50 seats in 2024 are re-pricing it at 2x to 3x the monthly run-rate in 2026. Foundation is free for 1 to 10 users with no feature gates and undercuts Structure at every paid tier.

Platform timing. Atlassian closed new Connect-app submissions to the Marketplace on September 17, 2025. Structure is a Connect app. Existing Connect apps keep shipping, but the platform direction is unambiguous: Forge is the future. Teams that plan to stay on Jira Cloud for another five years are re-evaluating their Connect-based tools now, before Atlassian's deprecation calendar forces the conversation.

Data residency. Foundation runs entirely inside Atlassian's cloud with zero egress by default. No Jira data leaves Atlassian infrastructure. Structure, as a Connect app, routes data through Tempo-operated external servers. For buyers in regulated industries — finance, healthcare, government — the residency difference alone is enough to trigger a switch.

Interface freshness. Foundation ships density modes down to 16 px per row, inline editing on every cell, a command palette, 2026-era keyboard shortcuts, and a Gantt with drag rescheduling. Structure's core UI was designed a decade ago and is still good, but teams that evaluated both in side-by-side demos consistently describe Foundation as “the one that feels like software made in this decade.”

What gets migrated and what doesn't

The single biggest anxiety in any tool migration is the unknown — what breaks, what silently disappears, what needs to be rebuilt. We publish the honest field-by-field picture up front so there are no surprises in the import summary.

What migrates cleanly (imports without edits):

Hierarchy tree — the full parent-child structure, at any depth, across any number of Jira projects.
Jira issue links — matched by issue key, so the same issue in Structure and Foundation points to the same Jira record.
Structure folders — rebuilt as Foundation Flex Items (non-issue nodes used for organizational grouping).
JQL-based generators — translated to Foundation's JQL Insert Sync Agent with the same query, same filters, same refresh cadence.
Parent/sub-task extenders — mapped to Foundation's Child Extend Sync Agent.
Standard Jira columns — Status, Assignee, Priority, Story Points, Labels, all dates, etc.
Saved views and column sets — each Structure view becomes a Foundation view within the same Lens.
Permissions and ACL grants — preserved when the grantees are Atlassian users or groups.
Gantt dependencies — when stored as standard Jira issue links (blocks / is blocked by).

What doesn't migrate (flagged in the summary for manual review):

Expr formula columns — Structure's Expr language has no equivalent in Foundation until the formula engine ships in Q1 2027. These are the biggest items to plan around; see the dedicated section below.
Exotic generators — saved-filter, agile-board, and linked-issue generators are not auto-translated yet. They are listed in the summary so you can rebuild manually using JQL Insert.
Multi-level transformation chains — Structure transformations more than one level deep are not imported. Single-level transformations do migrate.
Historical baselines — only the current snapshot migrates; prior baselines stay in Structure if you need them.

What you need before you start

Gather these four items before opening the wizard. Having everything staged turns a 45-minute migration into a 20-minute migration.

Atlassian admin access — needed once, to install Foundation from the Marketplace. If your admin has already installed it, skip this. Atlassian's admin roles documentation explains the relevant permissions.
A Structure Cloud API token — generated inside Tempo's Structure UI. Read scope is sufficient. See the Structure Cloud REST API docs for token generation.
A test Jira project — or a non-critical Structure to migrate first, so you can validate the import pattern without touching production portfolios.
A 30-minute focused window — most of it is the async job running in the background, but you want 15 uninterrupted minutes for review and spot-checking.

Step 1: Install Foundation side-by-side with Structure

Sign into Jira as an admin, open the Foundation Marketplace listing, and click Install. Foundation is a Forge app — the install is a single click, takes about 45 seconds, does not require a Jira restart, and does not prompt for OAuth consent for every user.

Foundation and Structure coexist on the same Jira site without conflict. They read from the same Jira issues but maintain separate hierarchy stores (Structure on Tempo's servers, Foundation in Forge SQL inside your Atlassian cloud). A Jira issue can appear in a Structure structure and a Foundation Lens simultaneously; edits made in either tool flow back to Jira and show up in both. Atlassian's app-management docs cover the general install flow.

Step 2: Generate your Structure API token

Open Structure Cloud, click your profile avatar in the top-right, and choose API Tokens from the menu. Click Create Token, give it a name like “Foundation migration,” select read scope, and copy the token string immediately. Tempo only displays the token once — if you close the dialog without copying, generate a new one.

The token inherits your Structure access permissions. If you can read a structure in the Structure UI, the token can read it during import. The token does not need write access because the migration is one-way into Foundation.

Step 3: Run the Structure Cloud Import wizard in Foundation

Open Foundation from the Jira app switcher. On the Foundation Home screen, click Import in the top-right header and choose Import from Structure. The wizard prompts for your Atlassian cloud region (so Foundation calls the correct Structure Cloud endpoint) and the API token you copied in Step 2.

Foundation validates the token with a lightweight API call before advancing. If the token is malformed or lacks read scope, the wizard shows a specific error — no silent failures. Once the token validates, Foundation queries Structure for every structure the token can access and displays a list with item counts, last-modified dates, and owner names. Tick the structures you want to migrate. One structure becomes one Foundation Lens by default.

For each selected structure, you can configure per-structure import options: hierarchy (required), generators (mapped to Sync Agents where the semantics match), saved views, and permission grants. The wizard shows defaults; most teams accept them without changes.

Step 4: Review the migration preview

Before Foundation writes anything to Forge SQL, the wizard shows a full preview for each selected structure:

Hierarchy summary — total nodes, issue nodes, folder nodes (becoming Flex Items), and max depth.
Generator map — every Structure generator, the Foundation Sync Agent it will translate to, and a clean/flag status.
Attribute map — custom Structure attributes and which Foundation columns they map to; unmappable attributes are listed explicitly.
Review-needed list — items that will not migrate automatically, with the reason for each. This is where Expr formula columns appear.

If the preview reveals a problem, cancel the wizard — nothing has been written. Fix the issue in Structure, regenerate the preview, and proceed when the summary looks right.

Step 5: Validate on a test Lens

Once the async import completes (you get a completion summary with links to each new Lens), open the smallest imported Lens first and run through this five-item checklist:

Row counts — does the total row count match the source structure? Small discrepancies (1 to 3 rows) usually mean a non-issue node type did not translate; check the import summary.
Hierarchy integrity — expand the tree to depth 3 or 4 and compare parent-child relationships against Structure.
Inline edit — click a Status cell and transition an issue. Verify the change appears in Jira within 5 seconds.
Sync Agent refresh — right-click a Sync Agent node and choose Refresh. Verify the new issues from Jira appear.
Permission grants — confirm any Structure ACL grants translated correctly; re-grant if needed using Foundation's permission UI.

Repeat the checklist on your largest imported Lens before moving to Step 6.

Step 6: Cut over

This is the calmest step in the migration because you have already done the hard work. Run both tools in parallel for at least one sprint — let your team use Foundation for new portfolio work while Structure stays live for anything mid-flight. After one sprint of parallel usage, most teams find their daily workflows have naturally migrated.

Flag stakeholders: send a team-wide message that Foundation is now the default portfolio tool, point to your imported Lenses, and link to an internal Foundation onboarding page (we ship a template). For teams with 50+ users, consider a 30-minute internal demo session so power users see the differences in keyboard shortcuts and inline-edit patterns.

Cancel Structure on your next Tempo renewal date — not mid-cycle. Tempo does not pro-rate mid-cycle cancellations, so cancelling three months early means leaving three months of pre-paid money on the table. The parallel-run period costs nothing extra because Foundation is free under 10 users and affordable at scale.

How to handle formulas during migration

This is the honest caveat. Structure's Expr formula language is its deepest moat — 100+ functions, weighted roll-ups, custom conditional columns, scripted aggregations. Foundation does not match it in the MVP; the formula engine is on the public roadmap for Q1 2027.

If portfolio reporting in your organization depends heavily on Expr, you have three options:

Wait. Run both tools in parallel until the Foundation formula engine ships, then re-migrate those reports. Foundation is free under 10 users, so pilot teams can evaluate the rest of the product today without a budget conversation.
Replace formulas with Sync Agent attributes. Many Expr formulas are really “give me the rolled-up count of issues matching X” — which translates to a JQL Insert Sync Agent plus a column. Rebuild the simpler ones this way and gain most of the reporting value.
Replace formulas with saved views. If a formula is really about filtering (“show only overdue epics”), Foundation's conditional formatting rules and saved views usually do the job without a formula engine at all.

For deeper context on the formula gap, see Foundation vs. Structure, which covers the trade-off in more detail.

Common migration issues and fixes

Four patterns account for 90% of migration questions we see.

Large hierarchies take longer than you expect. A 10,000-issue structure with 20 generators can take 40 to 60 minutes to import, because the job is bound by Structure Cloud's own API rate limits — Tempo's servers, not Atlassian's. The async job runs in the background; close the browser and come back. There is no rush. The fix is to stage the import: migrate one or two small structures first to validate the pattern, then kick off the big one.

Custom field mappings need tweaking. If you use the same Jira custom field across multiple projects with different configurations, Foundation imports using the first configuration it sees. After import, open the Lens columns panel and re-map the field if needed. This is usually a two-minute fix per Lens, not a re-import.

Jira workflow mismatches surface as status-transition errors. If a Structure structure spans projects with different workflows, inline status edits in Foundation may show unexpected transition options. This is Jira behavior, not Foundation behavior — the fix is to standardize workflows across the projects, which was already causing Structure-side pain.

Permission gaps. Structure ACL grants at the structure level do not always translate one-to-one with Foundation's Lens-level grants. After import, review the permissions on each migrated Lens and re-grant as needed using Foundation's Sharing UI. Foundation falls open on missing grants during Jira-side outages, so an incomplete ACL will not break visibility — but do audit before cutover.

What to do after migration

Once the parallel-run period is over and Structure is cancelled, spend an afternoon on three activities that compound value:

Review Foundation's Flex Items. Flex Items are non-issue organizational nodes — imagine folders, but smarter. Use them for program headers, portfolio quarterly buckets, theme groupings, or temporary sort containers. They replace the pattern of creating dummy Jira issues for organizational purposes, which Structure users often default to. See Lenses for how Flex Items fit into the hierarchy model.

Set up Sync Agents for automatic hierarchy rebuild. The best way to avoid a future migration is to make the hierarchy self-maintaining. Configure a JQL Insert Sync Agent per top-level program, Child Extend for Epic-to-Story rollups, and let the hierarchy rebuild itself from Jira truth every time an issue changes. Event-driven Forge triggers keep it fresh without consuming Jira API points.

Train the team. Foundation has fewer power-user quirks than Structure, but power users love keyboard shortcuts, the command palette (Cmd+K), density modes, and the inspector panel. A 30-minute internal demo pays for itself.

Parallel-run is the default, not the exception. Foundation does not require you to cancel Structure first, does not require a migration-complete attestation, and does not charge extra for overlap time. Every team we work with runs both tools for at least one sprint.

Frequently asked questions

How long does a Structure-to-Foundation migration take?

For a typical small-to-mid structure (under 1,000 issues with three or four generators), plan on 15 to 20 minutes of wall-clock time end-to-end: install Foundation (2 min), generate a Structure API token (2 min), run the import wizard (5 to 10 min of background async work), review the summary (3 min), and spot-check one Lens (3 min). Larger portfolios — 5,000 to 10,000 issues, 10+ generators — typically finish in 30 to 45 minutes because the import is bound by Structure Cloud's API rate limits, not Foundation's. You can close the browser during the async job and come back to a completed summary.

Will migration disrupt my team?

No. The import is strictly read-only against both Structure and Jira. Foundation calls the Structure Cloud REST API to pull structure metadata, hierarchy, and generator definitions, then writes its own copy into Forge SQL inside your Atlassian cloud. It never modifies a Structure structure, never edits a Jira issue, and never sends a write back to Tempo. While migration is running, your team continues using Structure exactly as before. After cutover, the same Jira issues are visible in both tools because both read from Jira as the source of truth.

What happens to my Structure licenses during migration?

Nothing. Your Tempo subscription is billed independently of any Foundation install, and the Atlassian Marketplace does not notify Tempo when you install Foundation. You keep paying Tempo exactly as before for as long as you want. The recommended pattern is to run both apps side-by-side for one or two sprints, validate that Foundation covers your team's workflows, and cancel Structure on your next Tempo renewal date rather than mid-cycle so you do not lose pre-paid time.

Can I migrate back to Structure if something goes wrong?

Yes. Because the import is one-way and non-destructive, your Structure data is exactly where it was before you started. If Foundation does not work for your team, uninstall it from the Atlassian Marketplace and Structure is untouched. There is no rollback script to run, no re-import to perform, and no data loss — both tools read from the same Jira issues, so cancelling the Foundation experiment leaves your Structure workflow in place.

Do my Jira users need to do anything during migration?

No end-user action is required. Individual Jira users do not install Foundation themselves — a Jira admin installs it once at the site level from the Atlassian Marketplace, and every user with Jira access sees it. Users who do not touch portfolio views are entirely unaffected. Users who do use Structure keep using Structure during the parallel-run period; once you flip the cutover flag, they open the Foundation globalPage link instead. No new accounts, passwords, or training prerequisites.

What about Structure.Gantt (Tempo Gantt Charts)?

Foundation ships a built-in Gantt chart in the Advanced edition, so the Tempo Gantt Charts add-on is not required post-migration. The Foundation Gantt supports all four dependency types (FS, SS, FF, SF), critical-path highlighting, four zoom levels, baselines, and drag-to-edit bars — equivalent to Structure.Gantt for the vast majority of plans. The import wizard detects Gantt dependencies in your Structure data (when they are stored as Jira issue links) and preserves them. Resource-allocation views from Structure.Gantt are not part of the Foundation MVP; if resource histograms are central to your workflow, that is a reason to stay on Structure until the post-MVP release.

Does migration require Jira admin access?

Jira admin access is required for the one-time install of Foundation from the Atlassian Marketplace — the same way installing any Jira app works. Admin access is not required for the migration wizard itself. Once Foundation is installed, any user with a Structure API token and Jira browse permission can import their own structures. If your Jira admin already installed Foundation, you can run the migration yourself without filing another IT ticket.

Will my JQL generators keep working?

Yes — with a translation step. Foundation reads each Structure generator during import and maps it to the closest Foundation Sync Agent. JQL-based generators translate cleanly to Foundation's JQL Insert Sync Agent: same query, same filters, same refresh behavior. Parent-child and sub-task extenders map to Foundation's Child Extend Sync Agent. More exotic generators (saved-filter, agile-board, Expr-driven) are flagged in the import summary as 'review needed' so you can decide how to rebuild them. Most teams find that 80% to 90% of their generators translate without edits.

How we tested migration

In March 2026, we migrated a representative Structure Cloud portfolio end-to-end into Foundation to validate the claims on this page. The source was a 500-issue structure across three real Jira projects (one Scrum, one Kanban, one service management), with three JQL-based generators, five custom attributes, two saved views, and eight ACL grants. We ran the Structure Cloud Import wizard from a clean Foundation install and measured end-to-end time from clicking Install on the Atlassian Marketplace to opening a validated Lens.

Total wall-clock time: 18 minutes 40 seconds. Install: 52 seconds. Token generation: 1 minute 20 seconds. Wizard configuration: 2 minutes. Async import: 11 minutes 30 seconds (bounded by Structure Cloud API rate limits, not Foundation). Preview review: 1 minute 10 seconds. Spot validation: 1 minute 48 seconds. All three generators translated cleanly to JQL Insert Sync Agents with no edits. Four of the five custom attributes mapped automatically; the fifth (an Expr-derived column) was flagged for review as expected. All eight ACL grants preserved. Zero Jira issues modified during import. Zero Structure data modified during import. The test is repeatable and we re-run it each quarter when the import wizard ships updates.