The Connect Cliff Is Closer Than the Marketplace Leaderboard Suggests

We have been on the Forge platform since it was a developer preview that did not yet have a Marketplace, building our own apps and shipping client work on it long enough to have opinions. The thing that keeps surprising us, in client conversations through the first half of 2026, is how many vendors with serious Connect apps are still treating the migration as a "we will get to it before the cliff" problem.

The cliff is closer than that timeline allows. Atlassian's own published deadlines have shifted twice and the current dates are, in our reading, the last set that will hold. The reason it is closer than the deadline alone implies is that the migration is not a port. For more apps than vendors want to admit, the migration is a partial rewrite — and for a smaller but non-trivial set, the honest call is that there is no Forge equivalent of what the app currently does.

This piece is about what we keep watching teams underestimate. We covered the platform comparison in Forge vs Connect in 2026 earlier in the year. This one is about the part that comes after the comparison: assuming you have decided to migrate, why is everyone running over time.

The lift-and-shift fantasy

The first thing we hear when a Connect vendor starts thinking about Forge is we will just port it. The implicit model is that Connect and Forge are both "platforms for building Jira apps", they probably have similar abstractions, and most of the work will be translating the manifest format and wiring up the new SDK.

This is true for a small percentage of apps. It is true for an app whose UI is a single panel, whose backend is two REST endpoints that respond to webhooks, and whose storage is a handful of small JSON blobs. If your Connect app is genuinely that shape, congratulations — you can probably do the migration in a fortnight.

For everything else, the honest pattern is that the application architecture needs to change, not just the deployment target. Forge has a different runtime model, a different storage model, a different egress model, a different UI surface model, and a different way of expressing scheduled work. None of these are catastrophic individually. Together, they mean that "porting" usually turns into "rebuilding the same app on a different paradigm", and that takes the time it takes.

The runtime that is not Lambda even though it looks like Lambda

Forge functions look like serverless functions because they are. The difference, and the one that catches teams out, is what they are not allowed to do.

No long-lived connections. No background threads. No process state between invocations. No outbound network calls to a host you have not put on the egress allowlist and got approved for in your manifest. The 25-second timeout is more generous than it sounds until your app has a feature that involves chunking through a Jira project with 40,000 issues — at which point you discover you need to re-architect it as a series of scheduled triggers and a queue, none of which existed in your Connect app.

The teams that hit this hardest are the ones whose Connect app has a single endpoint that does quite a lot. Bulk-import operations, sync jobs, anything that touches every issue or every user — these were trivial to build on Connect because Connect was just an HTTP endpoint that you operated yourself. Forge wants you to think in steps, with checkpoints, and that means the code you wrote in 2019 needs new bones.

Storage limits that are tighter than the docs make them feel

Forge KV storage is fine for most things. It is not fine if your Connect app has been quietly building up a 12 MB project-config blob over five years of feature flags being added one at a time. The 1 MB per-key limit is a hard wall, and the migration is not "make the blob smaller" — it is "redesign your storage schema so that each key holds a coherent, bounded slice of data".

We have audited Connect apps where the storage redesign ended up being the most expensive part of the entire migration. Six weeks of work that nobody on the original team had budgeted for, because on Connect they were just dumping JSON into a database they controlled and never had to think about it.

The other quiet trap is eventual consistency. Forge KV is consistent within a region, but the strict-read-after-write guarantees Connect users took for granted are subtly different here. Code that worked on Connect because the database was read-after-write consistent can produce ghost-read bugs on Forge that only show up under load.

The egress conversation

If your Connect app calls anything outside Atlassian — a webhook target, a third-party API, your own backend — you need it on the Forge egress allowlist. Adding hosts is not just a manifest edit. It is a manifest edit plus a security review plus an explanation of why your app needs to talk to that host plus a willingness to wait for Atlassian's approval cycle.

This is fine if your egress targets are stable and small in number. It is a recurring tax if you maintain a customer-configured webhook system, where the customer points the app at their URL. The Forge model of "we approve the egress targets" is in some tension with the Connect model of "the customer chooses the egress targets". There are patterns to resolve this — proxying through a vendor-controlled allowlisted host — but those patterns are themselves application-architecture changes, not migrations.

The UI surface that is smaller than vendors realise

Connect lets you place UI almost anywhere. Forge places UI in a defined set of modules, and that set is smaller than the equivalent on Connect.

We have looked at Connect apps that have UI surfaces with no Forge equivalent. The honest answer was sometimes that the migration would mean dropping that surface and finding a different way for the customer to do that thing. Most of the time the customer ended up fine with the alternative. Some of the time the missing surface was the entire product, and the migration question became should this product continue to exist.

This is the conversation Connect vendors find hardest to have, but it is the one that defines the timeline. If you assume your app's UI translates one-for-one to Forge, you will finish the migration and discover at submission time that the layout you depend on does not exist on Forge. We have seen this happen. The recovery cost is significant.

Apps that should not migrate

It is worth saying this out loud because nobody else will: a non-trivial number of Connect apps probably should not migrate. The honest move for some of them is to sunset.

Apps that exist in a category that has been substantially overtaken by native Atlassian functionality. Apps whose customer base has been declining for two years and whose migration cost would not be recovered before EOL anyway. Apps whose author wrote them in 2017 as a side project and has not really maintained them since. Apps that depend on Connect-specific behaviour that has no Forge equivalent and no acceptable workaround.

The vendors we respect most in this transition have been honest about which of their apps fit one of those descriptions. They are end-of-lifing the ones that do, focusing engineering on the ones with a future, and not pretending they have time to migrate everything. The rest of the market has not yet had this conversation publicly. They are going to have it under deadline pressure, which is the worst time to make those calls.

What an honest timeline looks like

If you have a Connect app of meaningful size and you have not started, the timeline is uncomfortable. From our experience auditing and shipping these migrations:

A genuinely small app — single panel, no scheduled work, vanilla storage — is four to six weeks of dedicated engineering time. You can probably do this before EOL even if you start late.

A medium app — multiple modules, background work, customer-configured webhooks, more than 100 customers — is three to four months. If you have not started, you are short on time. The Marketplace review queue is going to be congested in the back half of the year, which is not part of your engineering estimate but is part of the total time.

A large app — complex UI surfaces, big multi-tenant data, an ecosystem of webhooks and integrations, regulatory commitments to existing customers — is six months to a year, because most of the work is not the engineering, it is the customer-communication, the backwards compatibility, and the slow rollout. The cliff is non-negotiable if your goal is to keep paying customers.

We do not say any of this to alarm. We say it because we have audited enough of these projects in 2026 to be confident that the typical vendor estimate is half the right number. The vendors who started in late 2025 are looking comfortable. The ones who started in spring 2026 are looking tight. The ones who have not started yet are gambling on the deadline slipping again, and we do not think it will.

What we would do this week if we were a Connect vendor without a plan

Three things, in order, no slides:

The first is to honestly classify each of your Connect apps into "small / medium / large / sunset" and accept the verdict. The second is to start the migration on whichever app is most strategic and most realistic to finish before EOL — not necessarily the highest-revenue one, the one whose engineering risk is lowest. The third is to begin the customer-communication work in parallel, because some of your Connect-only behaviour will not survive and your customers deserve to know about it before the EOL email goes out.

We are doing this work for clients now, both auditing migration plans and executing the migrations themselves inside our wider custom-development service. The thing we cannot do for anyone is start the clock earlier than today. That bit each vendor has to do themselves.

---

If you have a Connect app and the migration is on the to-do list rather than the active list, we run a one-week scoped audit that classifies your apps, sizes the migration honestly, and tells you whether the EOL date is going to be a problem. Get in touch.