Zero-Downtime Migration Patterns for Jira PPM

Because Jira is the source of truth, PPM migrations between apps can be zero-downtime — both apps read the same Jira data simultaneously with no split-brain risk. Three proven patterns: shadow-and-cutover (fastest), read-replica (safest), and phased rollout (most org-friendly). Pick based on team size, risk tolerance, and how deep your Structure dependencies run.

Why is Jira PPM migration different from typical tool migrations?

A typical enterprise-tool migration — CRM, helpdesk, ERP — has to solve the split-brain problem. Each system owns its data, so running both live at once produces diverging records. The usual fix is a freeze window, the same expand-and-contract pattern database folks use for schema migrations: pause writes, migrate readers, flip.

Jira PPM migrations skip the freeze. Jira is the source of truth; PPM apps are view layers on top of it. Structure, BigPicture, and Foundation all read the same Jira issues. When a user edits a Status, Date, or Assignee in any of these apps, the write lands on the Jira issue — not on the app's data store. The hierarchy overlay (which issues belong to which parent) is stored per-app; the actual issue fields live in Jira.

Practical consequence: two PPM apps showing the same portfolio are not in conflict — they're two windows onto the same issue store. There's no “which copy is authoritative” question because neither holds a copy. Atlassian's own Cloud migration playbook is built on the same principle for whole-Jira moves; the intra-Marketplace case inherits it.

Pattern 1 — Shadow-and-cutover

The fastest pattern. Install the new tool alongside the old one, import hierarchies, validate for an afternoon to a week, flip user-facing links on a chosen date. Both tools stay live during validation; on cutover day, you remove the old tool from dashboards, update documentation links, and optionally uninstall.

When it works. Small teams (under 25 users), simple hierarchies, few custom automations, low-risk portfolios. One engineer, one afternoon. Our 10-minute Structure-to-Foundation migration is a shadow-and-cutover done in a single sitting.

When it doesn't. Anything with executive dashboards that need week-over-week continuity, or where a regression mid-cutover could land you in a post-mortem. The cutover window is too short to catch subtle issues — a Sync Agent that looked correct on Tuesday may reveal a missing custom field on Friday, after you've already flipped.

Sequence. (1) Install Foundation. (2) Import top 1–3 structures. (3) Run diff checks (row count, depth, three spot-check issues). (4) Soak for 2–5 days with both apps live. (5) Cutover: update link targets, change portal bookmarks, announce. (6) Keep old tool installed for one sprint as insurance. (7) Uninstall.

Pattern 2 — Read-replica

The safest pattern, borrowed from database operations. Set the new tool up as a view-only mirror for an extended soak — weeks, not days. Structure stays the write surface; Foundation is the read surface. Users LOOK at Foundation, still EDIT in Structure. You flip the write role only after every report, dashboard, and automation has been verified against the replica.

When it works. Mid-size orgs (25–200 users), risk-averse cultures, and shops with portfolio analysts who need time to port complex reports. Also the right choice when you haven't yet audited which custom fields and formulas actually matter.

When it doesn't. Budget for it — if your old tool charges the same for passive users, the soak period costs real money.

Sequence. (1) Install Foundation, import. (2) Announce “view-only mirror.” (3) Build parity dashboards alongside originals. (4) Spot-check weekly. (5) After 2–4 weeks of parity, announce write-cutover date. (6) Pin Foundation as the write surface. (7) Decommission at next renewal.

Pattern 3 — Phased rollout by team

Migrate one team at a time. Team A moves in week one, validates for a sprint; Team B moves in week two; and so on. This is the organizational-change pattern large companies use to deploy new tools: waves with champions in each team leading the way. Each migrated team becomes a reference for the next, so by wave three you've built internal expertise and moved faster.

When it works. Large orgs (200+ users) with many independent teams that own their own portfolios.

When it doesn't. If your org runs a single global portfolio — one “All Programs” structure used by everyone — phased rollout is architecturally impossible. You can't migrate one team's slice of a cross-cutting structure without moving the structure itself. Fall back to read-replica. Also skip phased rollout if teams share Sync Agents or JQL generators pulling across projects — those get messy across tools.

Sequence. (1) Identify a pilot team with independent structures. (2) Install Foundation org-wide (only the pilot team uses it). (3) Import, validate, cut over the pilot. (4) Retrospective: capture what breaks next. (5) Migrate Wave 2. (6) Repeat through Wave N. (7) Keep the old tool installed until the final wave; then decommission.

How do you choose the right pattern for your org?

The three patterns trade off along predictable axes: speed vs. risk, and coordination cost vs. coverage. This table is calibrated against the Jira PPM context specifically — generic “choose your migration pattern” tables don't bake in the source-of-truth assumption.

Pattern	Cutover time	Risk	Effort	Best for team size	Rollback complexity
Shadow-and-cutover	Hours to days	Low-medium	Low	Under 25 users	Trivial — re-point links back
Read-replica	2–4 weeks soak + hours	Lowest	Medium — build parity reports	25–200 users	Trivial — writes never moved
Phased rollout	Weeks to months	Low per wave	High — coordinate per team	200+ users, independent teams	Trivial per-wave; org reversal harder

A decision rule that holds up in practice: start from team size, then adjust for Structure-dependency depth. A 300-person org that all uses one global portfolio isn't a phased rollout — it's a read-replica. A 15-person team with a single Structure for their whole roadmap doesn't need a four-week soak; shadow-and-cutover is enough. For detailed license handling during overlap periods, see managing Structure licenses during migration.

What can go wrong (and how to catch it early)?

Most failure modes surface as visible mismatches rather than silent corruption, because the underlying Jira data is unchanged. Four patterns bite teams that didn't plan for them.

Custom fields with different project configurations. If the same field has different option sets across projects, Foundation imports using the first configuration it sees. Run a column diff on each top-level Lens before cutover — a 15-minute check that saves a 4-hour post-cutover fire drill.

Dual-write automations. An Atlassian Automation rule that writes on edit fires in both tools during overlap. Usually harmless (second write is idempotent), but sometimes double-increments a counter or sends duplicate notifications. Audit “when issue is edited” rules and temporarily guard them with an edit-source condition.

Formula-dependent reporting. If an exec dashboard relies on Structure's Expr for weighted roll-ups, those reports don't transfer — they're rebuilt. Not a migration failure; a rebuild scope item. But if you discover it three days before cutover, it becomes a failure. See the migration product page for the current coverage matrix.

JQL-query drift. If Sync Agents use JQL that references specific custom fields, confirm the field IDs (not just names) match after import. Jira custom fields are keyed by ID; a query can break silently if the ID differs.

What are the rollback options at each phase?

Rollback is easy in all three patterns until you cancel the old tool's subscription. Specifics vary by phase.

Before cutover. Trivial. The old tool is untouched; rollback is “do nothing with Foundation” (uninstall if you want to be thorough).

During overlap. Trivial. Keep using the old tool as the write surface. The new tool's view goes stale; that's fine because you weren't committed.

Immediately post-cutover. Trivial. Because Jira holds the truth, the old tool still reads the latest state. You may need to re-run a generator to pick up items added during Foundation-only time, but no data is lost.

After decommission. The first genuinely-hard rollback, which is why you decommission LAST. If Foundation fails post-decom, you reinstall the old tool — Jira data is still authoritative — but the hierarchy overlay must be rebuilt from whatever export you kept. Keep the old tool installed at least one full sprint after cutover, and export its hierarchy as JSON or CSV before cancelling.

Cancel the old subscription LAST. It's the one step you can't undo cheaply. Every other stage of a zero-downtime migration is reversible because Jira is the source of truth. Keep the old tool installed through at least one full sprint of post-cutover use before handing billing notice.

Frequently asked questions

Why is a Jira PPM migration easier than most tool migrations?

Because Jira is the source of truth for issues, dates, assignees, and links. Both the old PPM app (Structure, BigPicture, etc.) and the new one (Foundation) READ the same Jira data — they do not each hold their own copy of it. That means two PPM apps can display the same portfolio simultaneously from the same underlying records. Compare this to a typical enterprise migration (CRM, ERP, helpdesk) where each system owns its data and parallel operation risks split-brain. Jira PPM migrations have no split-brain risk on the issue layer.

Which pattern should a 10-person team use versus a 500-person org?

Small teams (under 25 users) almost always do shadow-and-cutover because the coordination overhead of phased rollout is not worth it at that scale — one afternoon and it is done. Mid-size teams (25 to 200) usually benefit from read-replica because the risk of a bad cutover is high enough that a safety window is worth building. Large orgs (200+) should default to phased rollout, migrating one team at a time. The exception: large orgs with a single global portfolio used by everyone cannot do phased rollout and must use read-replica instead.

What does "zero-downtime" actually mean here — is there no disruption at all?

Zero-downtime means your Jira data remains continuously available and writable throughout the migration. It does not mean zero change management. Users still need to learn the new tool, saved views may need re-creating, and some reports may have to be rebuilt. But at no point is the portfolio blind, nobody gets locked out, and no issue goes into a read-only state. Contrast with database cutovers where you often need a freeze window — Jira PPM migrations never need that freeze because the database (Jira) is not being cut over.

Can I pause or roll back mid-migration?

Yes, at every stage. Since both tools READ from Jira without modifying each other's state, nothing you do in Foundation affects Structure (or vice versa). If week two of a phased rollout reveals a blocker, the migrated team reverts to Structure by reopening the same structures — their data was never moved. The only truly non-reversible step is cancelling your old tool's subscription, which you do LAST, on a renewal date, after validation is complete.

What breaks zero-downtime assumptions?

Three things. First, tightly-coupled cross-team portfolios where one "global structure" is referenced by every team — you cannot migrate one slice without migrating all of it. Second, heavy dependence on formula columns (Structure's Expr language) that have no analogue in the target tool — those reports are effectively rebuilt, not migrated. Third, write-back automations (a Gantt edit that writes an Atlassian Automation rule trigger) can fire twice if both tools are active. Audit these before cutover, not after.

How do I validate the new tool matches the old one before flipping?

Run a row-count diff, a hierarchy-depth diff, and a spot-check of three representative issues across both tools. For each spot-check issue: verify its parent in both apps is the same Jira key, its assignee matches, its dates match, and any link-based dependency is visible in both. If all three match on every dimension, the source-of-truth layer is consistent. Any mismatch almost always traces to a Sync Agent (or generator) not having been re-run recently — refresh it and recheck.