Atlassian Connect End of Support on 31 January 2027: Moving Custom Jira and Confluence Apps to Forge

one red jigsaw piece lying among green ones

On 31 January 2027 Atlassian ends support for Connect, the framework most older Jira and Confluence Cloud apps were built on. From that day, Atlassian says it "will only address critical security vulnerabilities in Connect", and a private app still running on Connect "will no longer be supported and may stop working properly".

If every app on your site came from the Atlassian Marketplace, this is your vendors' job, and most of them have done it: Atlassian reported in August 2026 that "over 95% of paid app seats have been migrated to Forge".

This article is for the other case. Your company has a Jira or Confluence app that somebody built for you: an internal developer, a contractor, a partner. It was installed by link, not bought. Nobody outside your company is going to move it, and the person who wrote it may not be around any more.

What End of Support Means, and What It Does Not

There is no published switch-off date. Atlassian has not said that Connect apps stop running on 1 February 2027, and its original timeline announcement said that "customers who have Connect apps installed won't lose access to the app".

Do not read that as safety. What changes is that nobody at Atlassian looks after Connect any more:

Only critical security vulnerabilities get fixed. Non-critical bugs stay.
"Connect feature deprecations will happen with little notice."
Atlassian Support "will not be able to fix issues caused by that legacy technology".
In Atlassian's own words: "Connect will not remain in a steady state after end of support. Breakages will increase and compatibility gaps will widen."

So the risk is gradual, not a cliff. A plausible failure: Jira changes a page, a Connect panel stops rendering, and there is nobody to raise a ticket with. If that app sits inside a finance approval or a customer-facing service desk, you hear about it from the people who depend on it.

What Has Already Happened

The January date is the last step of a sequence that started in 2025.

September 2025: the Marketplace stopped accepting new Connect apps.
31 March 2026: updates froze. Atlassian's guidance for custom apps put it plainly: after that date "you'll no longer be able to push updates to Connect apps". Code on your own server is still yours to change, but what the app declares to Jira or Confluence (its modules, scopes and webhooks) is fixed.
March 2026: the timeline also said "the ability to install new Connect private apps via Connected Apps will become unavailable". Treat an uninstall as one-way: do not remove a private Connect app just to see what breaks.
August 2026: Atlassian moved end of support from December 2026 to 31 January 2027. That is one extra month. Do not plan on another.
Now: Atlassian is rolling out warnings in Atlassian Administration, where private apps still on Connect are "marked with the LEGACY status".

Finding Your Private Apps

Start in Atlassian Administration, on the Connected Apps page. Anything labelled LEGACY is running on Connect. Atlassian's checklist for spotting a private app: if most of these are true, it is yours to move:

installed via a direct link or developer mode, not from the Marketplace;
not visible in Marketplace search;
your organisation maintains the source code;
no licensing information, and your organisation is the only one listed under installations;
no related links sidebar on its Connected Apps page (Marketplace apps have one).

Atlassian adds a rule of thumb: a custom cloud app built more than five years ago is likely a Connect app, and Connect apps are hosted outside Atlassian, "typically on a service like Heroku, AWS, Azure, or Google Cloud Platform". The app's View app details link shows who the developer is, as far as Atlassian knows.

For each app, write down five things before anyone touches code:

What it does and who uses it, in a sentence a business owner would recognise.
Where the source code is. A repository you control, a contractor's laptop, or nowhere.
Where it runs, and whose account pays for the hosting. If the server sits on a former contractor's cloud account, that is a risk today, not in January.
The descriptor. Every Connect app serves an atlassian-connect.json file at a URL. It lists every module, scope and webhook the app uses, which makes it the most reliable inventory you will get.
What data it keeps, and where: in its own database, or in properties stored on Jira issues and Confluence pages.

Decide Before You Build

Not every private app deserves a migration. Atlassian's own advice is to check whether a native Jira or Confluence feature now does the job, and to migrate only what the organisation still needs. Old apps often filled a gap the product has since closed.

Each app gets one of three answers: migrate, replace with something supported, or retire. Retiring is a legitimate outcome. Atlassian recommends that if you drop an app, you tell its users and schedule the removal before 31 January 2027, rather than leaving it to fail on its own.

What Moving to Forge Involves

Forge is not Connect under a new name. The hosting model, the security model and the UI model all differ, which is why Atlassian tells even the owners of simple apps to start a proof of concept early.

Hosting

A Connect app is a web service you run. A Forge app runs on Atlassian's infrastructure as functions with hard limits: 25 seconds for a function a user triggers, up to 900 seconds for async events and scheduled triggers. A Connect app that runs a ten-minute sync while the user waits has to move that work into async events, and anything longer than fifteen minutes has to be split into steps. Outbound calls are restricted as well: any domain not declared in the app's manifest is rejected.

Keeping the backend you have

Forge Remote lets a Forge app call services you host elsewhere, lets your server check that a request really came from Forge, and gives your backend tokens to call Atlassian APIs. For a private app with years of business logic on its server, this is often the shorter route: the UI and the integration points move to Forge, the logic stays put.

The trade-off: Forge Remote can make an app ineligible for Atlassian's Runs on Atlassian programme. For an internal tool that matters less, but your security team should accept it knowingly.

Authentication and permissions

Connect apps authenticate with JWT signed with a shared secret. Forge replaces that with OAuth 2.0 scopes declared in the manifest and, for remote backends, a Forge Invocation Token your server validates instead of a JWT.

Each authenticated call to the Jira or Confluence API is then made either asUser, with the permissions of the person using the app, or asApp, which in Atlassian's words works "regardless of who uses the app". Going through each call and choosing on purpose is the most important security review in the whole migration.

One difference catches teams out. Connect modules render for unlicensed and anonymous users by default; Forge modules do not, unless the manifest opts in with unlicensedAccess. If your app shows anything to service desk customers or anonymous Confluence readers, test that path on its own.

The user interface

Connect pages are iframes that talk to Jira or Confluence through Atlassian's JavaScript API. Forge gives you two options:

UI Kit: a React-based framework that renders native Atlassian components. Quick and consistent, but you build from Atlassian's components: custom HTML may not work, and the only static resources it accepts are images.
Custom UI: your own HTML, CSS and JavaScript in an iframe, talking to the product through @forge/bridge.

An existing iframe front end usually moves to Custom UI with the fewest changes. Small panels and settings screens are often quicker to redo in UI Kit.

Data

This is where migrations go wrong. Forge has its own hosted storage: a key-value store, a custom entity store, Forge SQL, and an object store in preview. Data is scoped per installation and kept in the same location as the host Jira or Confluence site, so data residency comes without extra configuration.

What that means for a private app:

Data in the Connect app's own database is either moved into Forge storage by a one-off migration job, or left where it is and reached through Forge Remote.
Anything the Connect app stored on Atlassian's side under its own app key should be exported while the old app still runs. Test early whether the new app can read it; do not assume.
Forge keeps hosted data for 28 days after an uninstall, but a reinstall does not restore it automatically.

Write the migration as a repeatable script with counts you can check, rehearse it on a test site, and keep the export.

The incremental path, and why it is probably not yours

Atlassian built a gentler route for Connect apps: adopt Forge incrementally, keep existing installations, convert the descriptor into a Forge manifest, and move one module family at a time, with built-in data migration for some modules such as macros, custom fields and workflow validators.

The catch is in the first paragraph of the guide: "The incremental adoption of Forge is only available for Confluence and Jira Connect apps that are already listed on Marketplace."

For a private app, plan on a new Forge app. You deploy it to the production environment, share it with your site through an installation link from the developer console, run it beside the old Connect app while data is migrated and users test, then remove the Connect app.

The adoption guides are still useful for their module mapping, and so is the list of Connect capabilities not available in Forge: several Jira Service Management modules and mobile app support are marked not planned, and jiraReports is still under consideration. Check your descriptor against that list in the first week. A gap there changes the design.

A Plan Back From 31 January 2027

From early October 2026 there are about seventeen weeks left, and December is short for everyone. A plan that holds:

This week: list every LEGACY app with the five facts above. Confirm who controls the source code and the hosting account.
By mid October: decide migrate, replace or retire for each app. Tell the users of anything being retired.
By the end of October: a Forge proof of concept for the hardest part of the hardest app. Usually that is a module with no direct Forge equivalent, or the one holding the most data.
November: build, and run the data migration against a test site more than once.
Early December: install the Forge app beside the Connect app, migrate a copy of the data, and let the people who use it every day check it.
January 2027: final migration, move users over, and remove the Connect app only after the new one has run cleanly for a while.

A single panel that reads Jira data and stores nothing is a small job. An app with its own database, workflow rules and links to other systems needs every one of those weeks.

If you miss the date, nothing Atlassian has published says the app stops that day. But you are then running a business process on a platform its owner has stopped fixing. Treat that time as borrowed, and finish the move.

When the Original Developer Is Gone

Atlassian addresses this case directly. If you cannot identify or contact the original app owner, or no longer have the development capacity, it suggests engaging a Solution Partner. It is equally clear that without the source code "it may be necessary to rebuild on Forge from scratch".

Even with no source code, you are not starting blind. The descriptor lists everything the app plugs into, its behaviour can be observed on a test site, and if your company pays for the server, you can see what is actually deployed. A rebuild from those pieces is slower than a port, but it is a known quantity.

Where to Get Help

We take over code nobody on the current team wrote, work out what it really does, and move it: for a Connect app that means reading the descriptor and the server, building the Forge app, and writing and rehearsing the data migration. Our legacy system maintenance work is usually where this starts, and if you have developers but not enough of them, staff augmentation adds people to your team for the duration. Tell us what the app does and where it runs: write to office@c9group.dev.