If your team gets Jira updates in Google Chat through Google's own app, Google Chat for Jira Cloud, this is a good moment to plan the switch. Here is what is changing, what to look for in a replacement, and how to move a space without losing a day of notifications.
What is changing
Atlassian apps are built on one of two platforms: the older Connect and the newer Forge. Atlassian has announced that Connect support ends on 31 January 2027. After that date Connect only receives fixes for critical security issues, and Connect features can stop working as the Atlassian platform moves on.
Google's app for Jira Cloud is a Connect app. According to its Atlassian Marketplace listing, its latest version was released in November 2021. It has about 11,000 installs and an average rating of 2.3 out of 5.
Nothing switches off on 1 February 2027. The risk is gradual: an app that no longer gets updates on a platform that no longer gets features tends to break at the worst possible moment, usually during a release.
Why move now, not in January
- No pressure test on release day. Moving a few spaces takes minutes, but checking that the right people get the right messages takes a week of normal work. Do it while nothing is on fire.
- A chance to fix the noise. Most complaints about the current app are about volume: every event from every project, each in a new thread. A move is the natural moment to decide what each space actually needs.
- Budget and approvals. If a paid replacement needs a purchase approval, Q4 is when those go through.
What to look for in a replacement
| Question | Why it matters |
|---|---|
| Is it built on Forge? | Forge is the platform Atlassian is investing in. Connect apps face the same end-of-support question. |
| Can you filter by project, JQL and status transition? | This is what separates a useful space from a muted one. "Only when an issue moves to Done" should be one setting. |
| Does each issue keep one thread? | Threads per issue keep a busy space readable; every event in a new thread does not scale. |
| How does setup work? | Setups that require every user to connect a personal Google account break on cookies and permissions. A space webhook set up once by an admin avoids that. |
| What data leaves Jira? | Check which fields are sent to Google Chat and whether restricted comments stay private. |
| Is there a delivery log? | When a message does not arrive, you want to see why without opening a support ticket. |
Moving, step by step
The steps below use Jaylert, which we build for exactly this move; the approach works the same with any webhook-based app.
- List your spaces. For each Google Chat space that gets Jira messages today, note which project it follows and what the team actually reacts to.
- Create a webhook in each space. In Google Chat: space name → Apps & integrations → Webhooks → Add webhook. Copy the URL.
- Create one rule per space. Pick the project, add a JQL filter if needed (for example
priority in (High, Highest)), choose the events, and set a status transition such as any status → Done where it helps. - Send a test message. A sample card with your chosen fields appears in the space.
- Run both for a day. Compare what arrives. Adjust filters until the new rule sends what the team needs and nothing else.
- Remove Google's app from the space (Apps & integrations) so nobody gets duplicates.
Checklist
- Every space that relied on the old app has a new rule and a successful test message.
- Busy spaces use filters or a daily digest instead of every event.
- The old app is removed from each migrated space.
- Someone knows where the delivery log is.
Questions about a specific setup? Write to us; we read every message.