If your organization runs Jira Cloud with any Marketplace or custom-built apps, the Connect-to-Forge migration is now a deadline on your calendar.
In March 2025, Atlassian officially announced the deprecation of Atlassian Connect. The timeline is firm:
Milestone | Date |
No new Connect apps on Marketplace | September 17, 2025 ✅ |
No updates to existing Connect apps | March 2026 ✅ |
Official end of support for Connect | Q4 2026 ⚠️ |
After Q4 2026, Connect apps will continue to run but "use at your own risk." No patches, no support, no new versions. For organizations running business-critical workflows on Jira, that's an unacceptable risk posture.
Understanding why Atlassian is making this move helps frame the migration decisions you'll need to make.
Atlassian Connect was built for the early cloud era. Apps run on your infrastructure (or a vendor's) and communicate with Jira via APIs and webhooks. This gave developers flexibility, but it also meant your organization was trusting external servers with your Jira data and vendors were responsible for uptime, security patching, and scaling.
Atlassian Forge is cloud-native and serverless. Apps run inside Atlassian's infrastructure. Atlassian handles hosting, scaling, and security. Each app installation is isolated ("zero-trust" model), and data never leaves Atlassian's environment unless the app explicitly calls an external service.
For decision-makers, this shift means:
There are two distinct scenarios you'll encounter:
These are apps built by third-party vendors. You don't migrate the code — your vendor does. Your job is to:
If your team built Connect apps internally, the migration is your engineering team's responsibility. This is where the complexity lives.
Forge is excellent but it's not a 100% feature-for-feature replacement for Connect yet. Here are the some constraints that affect planning:
Compute & Runtime Limits: Forge is serverless, which means Forge functions have execution time limits. Long-running processes (large data exports, bulk operations) need to be broken into smaller batches. This can require redesigning workflows, not just porting code.
Language Constraints: Connect apps could be written in any language your server could run. Forge runs JavaScript/TypeScript. Teams with Python, Java, or Groovy-based Connect apps will need to rewrite not just migrate their code.
UI Framework Limits: Forge offers two UI approaches:
If your app has a complex UI, Custom UI is usually the right choice. Trying to force a complex interface into UI Kit can cost weeks of rework.
Module Coverage Gaps: While Forge now covers 95% of Connect modules, some less-used Connect modules don't have Forge equivalents. Before committing to a migration timeline, verify that every module your app uses has a Forge counterpart.
Licensing Constraints: A paid Connect app must migrate to a paid Forge app, and unpaid to unpaid. The licensing status cannot change during migration. Apps with suspended licenses also cannot migrate those customers need to resubscribe first.
Authentication Changes: Connect uses JWT (JSON Web Token) for API authentication. Forge uses a different token system (Forge Invocation Token / FIT). Any custom integrations or external services your app calls will need to be updated to validate the new token format.
Data Retention: Module-level data migration (retaining existing data when replacing a Connect module with a Forge equivalent) is only supported for specific module types. Check the official compatibility matrix before assuming your data migrates automatically.
Migration is always disruptive but this one comes with a silver lining. Forge apps are more secure, more stable, and better aligned with Atlassian's product roadmap. New features from Atlassian are being built exclusively for Forge. Apps that complete migration early will benefit from faster update cycles (minor updates that don't require admin approval) and improved data residency compliance.
The organizations that treat this as a strategic refresh rather than a grudging technical obligation will come out ahead.
Further Reading
Excellent breakdown! Especially the way you separate “vendor migration” from “customer responsibility.” That distinction gets missed a lot, and it’s where many teams underestimate the real effort. Also appreciate you calling out the practical Forge constraints (runtime, module parity, auth, and UI tradeoffs) instead of framing migration as a simple lift-and-shift. That’s the part decision-makers need to understand early.
I also touched on the broader strategic implications of Atlassian’s platform shift in my article, especially why this move is bigger than just a framework migration. It’s really a change in how apps are expected to be built, secured, and governed going forward: https://community.atlassian.com/forums/App-Central-articles/The-Forge-Awakening-Why-Atlassian-s-Platform-Shift-Is-Bigger/ba-p/3185763