Most Jira admins I talk to are tracking one date: March 2029. Data Center end of support. That date is real and it matters. But while the industry has been debating migration timelines, a different deprecation quietly moved past its first two milestones — and Phase 2 is active right now, affecting every Atlassian Cloud instance that runs Connect apps.
If you haven’t been paying attention to this one, now is the time to start.
Two Frameworks, One Deprecation
If you’ve never had a reason to think about how Marketplace apps on Atlassian Cloud are actually built, here’s the short version.
Atlassian has two frameworks for building cloud apps: Connect and Forge. Connect is the older one — it’s been the dominant framework for years, which means a significant portion of the apps in your instance almost certainly run on it. Forge is the newer platform, more tightly integrated with Atlassian’s architecture and built to be more secure and scalable. It’s where the platform is going.
Atlassian announced Connect’s end of support in March 2025, and has been executing a three-phase deprecation since then. Phase 1 is done. Phase 2 is active. Phase 3 is coming at some point before the end of this year.
As an admin, none of this requires a deep understanding of how apps are built. What it does require is that you understand what it means for the apps you depend on — and what questions to ask of your app vendors before Phase 3 arrives.
The Three Phases, Explained for Admins
Phase 1: No New Connect Apps (September 2025)
As of September 17, 2025, no new apps can be submitted to the Atlassian Marketplace on the Connect framework. New apps must be built on Forge. This phase only affected vendors starting fresh — it had no impact on existing apps already in your instance.
If you blinked, you probably missed it. Most admins did.
Phase 2: Apps Are Frozen in Place (March 2026 — Active Now)
This is the first phase that would significantly impact admins, and it crossed in late March with almost no visibility outside of developer circles.
As of March 31, 2026, Connect apps can no longer update the configuration that defines where they live in your Atlassian products — what surfaces they appear on, what permissions they request, and what integration points they use. In developer terms, this is called the app descriptor. Vendors can still push bug fixes and improvements to what the app already does. But the app can’t grow.
What does that mean in practice? If a new feature requires the app to appear somewhere new in your Jira or Confluence interface — a new panel, a new admin page, a new integration with another product — it’s impossible under Connect. If it needs access to permissions the app doesn’t currently have — blocked. If the vendor wants to expand what the app connects to in your instance — can’t be done.
The ceiling is fixed. Vendors can paint the walls, but they can’t add rooms.
Phase 3: Use at Your Own Risk (Q4 2026)
The third phase has no hard date yet — Atlassian has said “sometime in Q4 2026.”
When Phase 3 arrives, Connect enters full end-of-support status. Atlassian will no longer investigate or remediate breaking changes caused by product or platform updates. This is the important distinction: Phase 3 is not a hard cutoff like Data Center EOL in 2029, where everything stops on a specific date. It’s closer to what happened with Atlassian Server — apps keep running, nothing gets forcibly removed, but without Atlassian maintaining compatibility, the platform gradually evolves around them. Each product release that ships without a consideration for Connect is another small gap. Each API change that breaks something in a Connect app and doesn’t get patched is another crack. The apps don’t stop on a date — they degrade over time.
If that sounds familiar, it should. Atlassian admins who stayed on Server past EOL know exactly what this trajectory looks like. The difference with Connect Phase 3 is that the degradation is driven by active platform evolution, not just age. Atlassian is shipping Forge features and integrations constantly. Connect apps can’t follow.
The risk compounds. An app that works fine in Q4 2026 may behave unexpectedly in Q2 2027. There’s no committed timeline for how long “works for now” actually lasts.
The In-Product Warnings Are Here
Starting the week of May 25, 2026, Atlassian began rolling out in-product banners across Jira, Confluence, and admin.atlassian.com that flag exactly which installed apps are still running on Connect.
This is one of the more useful things Atlassian has done for admins in this whole deprecation cycle. Before this rollout, auditing your Connect exposure required either manual cross-referencing or third-party tools. Now it’s surfaced directly in your admin console.
It hasn’t been universally welcomed, though, and the vendor complaints are fair. Atlassian has been surfacing these banners to all users, not just admins, throughout the product. For an app that’s already mid-migration, that drops a scary-looking warning in front of customers about a problem that’s actively being solved. So read the banner for what it is: an inventory of what’s running on Connect, not a verdict on any single app. It tells you an app uses Connect. It doesn’t tell you whether the vendor ships the Forge version next month.
Check admin.atlassian.com → Apps (or your Jira/Confluence app management pages) now. The banners identify affected apps by name. This is your starting inventory.
If you haven’t seen a warning yet, it’s still rolling out — but it’s coming to every org.
The Question Every Admin Needs to Ask
The in-product list gives you the “what.” The more important question is “now what” — specifically, what is each vendor actually doing about it?
The first tool I’d point you to is forge-apps.com, a free tracker built by Seibert Group that shows the platform status of every Marketplace app: Connect, Forge, or somewhere in the middle of a migration with a percentage completion indicator. Run your impacted apps through it before you start making calls. It’ll save you a lot of time on apps that are already well into their Forge migration.
For apps that show as Connect with no migration progress, that’s when you need to go to the vendor directly. The question I’d ask is direct: “Can you show me your Forge migration roadmap?”
Here’s what a healthy answer looks like: there’s a published timeline, an active Forge version on the Marketplace or in development, and some communication to customers about what the transition plan looks like. Some vendors are partway through — a Forge version exists for some products but not all, or they’re migrating feature by feature, or they’ve shipped a “Connect-on-Forge” intermediate step that satisfies Phase 2 requirements while they finish the full native Forge build.
Here’s what a concerning answer looks like: no public statement about migration, no Forge version visible on the Marketplace, a support ticket that produces a form response, or radio silence after you ask directly.
A vendor who can’t show you evidence that migration is actively underway is telling you something about their investment in the product.
What a Real Migration Looks Like (vs. Quiet Abandonment)
I want to give you a realistic picture of what vendor migration actually looks like, because the timelines are relevant to how you interpret what you hear back.
Migrating from Connect to Forge is not trivial. Forge is a fundamentally different execution model — apps run inside Atlassian’s infrastructure, with different APIs, different security constraints, and different development tooling. For a complex, mature Connect app, a full native rebuild can stretch to a year or more. That said, a timeline that long usually reflects blockers like waiting on Forge to reach feature parity, not the migration work itself; an app without those gaps can move a lot faster. Many vendors take an incremental path called Connect-on-Forge, which brings an app onto Forge piece by piece instead of in one big-bang migration. It’s easy to read that as a stopgap, but it isn’t one. It lets a vendor adopt Forge progressively while still shipping updates, rather than freezing the app until a full rewrite is finished. For a lot of mature apps it’s the smarter route, not a lesser one.
I don’t have to reach for a hypothetical to show you what that costs. When Nelson Pereira of ikuTeam came on The Jira Life (full disclosure: ikuTeam sponsors the show this quarter on TJL), he was blunt about the path they chose, and it’s exactly the distinction that matters here:
“A lot of vendors are building a small wrapper in Forge using remotes, and that’s it. What we did was take the opportunity not just to move to Forge, but to look back at six or seven years of code and rebuild it from scratch.”
To be clear, he isn’t knocking the incremental path. For plenty of vendors, adopting Forge piece by piece while they keep shipping is exactly the right call. ikuTeam just decided that since they were going to be in the code anyway, they’d rebuild on the new foundation instead of bolting onto the old one.
That decision cost them close to a year with, in his words, no new features shipped. A big part of why it ran that long is that Forge itself wasn’t ready for everything they needed; they were waiting on feature parity that only landed late last year. They told customers the roadmap was paused while they did the work, and some customers left over it. “We lost a couple of them, I’m not going to lie,” he said. “But that’s how business works.”
The payoff is the kind of capability Connect simply can’t reach anymore: letting Rovo reason over a Confluence page and its SharePoint attachments at once, while still respecting who is allowed to see what. And it only works, as Nelson put it, because they went all in instead of straddling both frameworks. That is what a serious migration looks like from the vendor’s side. It’s a deliberate, expensive trade where the roadmap goes quiet on purpose so the platform work gets done right, and the vendors worth keeping are the ones willing to make that trade and able to tell you plainly where they are in it.
Vendors who are genuinely invested tend to be transparent about where they are in that process. There’s a community post, a roadmap item in their public tracker, a support article that acknowledges the timeline. They don’t have to have a firm date — but you should be able to see forward movement.
Vendors who have quietly deprioritized tend to go quiet. Updates slow down. Marketing continues, but technical progress doesn’t. The Connect app still works because it still runs — but there’s no sign anything is changing.
Keep the risk in proportion, though. If an app brings in meaningful revenue, the vendor is almost certainly migrating it; the economics make that call for them. The real exposure sits with the marginal apps: small utilities, niche tools, anything that already looks half-abandoned. And size isn’t the tell here. A small vendor can be fully committed to its product, and a large one can quietly let an app rot. What you’re weighing is whether the app is actively maintained, not how big the company behind it is.
The difference matters because “this app works today” and “this app will still work reliably in 2027” are different statements. After Phase 3, they diverge.
If You’re Stuck on a Critical App With No Path Forward
If your app audit turns up a business-critical tool running on Connect with no migration plan from the vendor, you have a few options worth thinking through now — before Phase 3, not after.
Check for Forge-native alternatives. The Connect-to-Forge transition has been a forcing function for competition in some app categories. Some categories that were previously dominated by a single Connect app now have multiple Forge-native options. A competitive landscape audit is worth the time.
Evaluate native capability. Atlassian’s platform has been expanding — Jira Automation, Rovo, and Atlassian’s own toolset have absorbed functionality that previously required third-party apps in some areas. This isn’t always a straight substitution, and I’d be skeptical of anyone who tells you it is without specifics. But it’s worth auditing whether the specific capability you depend on has a native path.
Get a written commitment from your vendor. Even if an app technically runs after Phase 3, you want clarity on what vendor support looks like when it breaks in an environment Atlassian is no longer maintaining compatibility for. A vendor who is serious about their product will tell you. One who isn’t will dodge.
The worst outcome is getting to Q1 2027 and discovering that a process your team relies on broke silently while nobody was watching the app. That’s a preventable problem.
Start Now, Not Later
March 2029 is the date everyone has circled in red on their calendars, because it’s a real hard stop. That’s the DC EOL, and when we cross it, most work on DC stops dead.
Connect Phase 3 doesn’t work like that. It’s slower and quieter, more like what happened to Server after its EOL. Nothing breaks on day one. Apps keep running. It may be a few days before you see anything… wrong. Or it could be months or even years. But the platform moves forward without them, tick by tick, and the compounding effects show up gradually — a broken integration here, an unsupported feature there, a vendor who stops responding because they’ve moved on. By the time something critical fails, you’ve lost the window to respond deliberately.
A few hours of app estate work now — the in-product warnings give you the inventory, forge-apps.com gives you the migration status, and a direct conversation with each critical vendor tells you whether they’re actually moving — is worth a lot more than the scramble that comes after Phase 3 lands and something you depend on silently starts degrading.
The 2029 date gets all the attention. But the clock that’s actually running already started.
What makes this one easy to ignore is that nothing forces your hand. There’s no assistant to run, no instance to rebuild, no hard date on the calendar. Just a slow drift you don’t notice until something you relied on quietly stops working. So take this as the nudge to spend an hour in your admin console this week, while the choice is still yours to make calmly. And if you turn up a business-critical app stranded on Connect with a vendor who’s gone quiet, come tell me about it over on The Jira Life. Comparing notes on who’s actually migrating and who’s just coasting is half of what we do there every week.
Until then, this is Rodney, asking: have you updated your Jira issues work-items today?
Discover more from The Jira Guy
Subscribe to get the latest posts sent to your email.
The Jira Guy 