For many Jira users, “Connect vs Forge” sounds like a vendor-side technical detail. In reality, it is much bigger than that. It affects how apps evolve, how they fit Atlassian’s platform direction, how enterprise customers evaluate trust, and how confidently vendors can plan for the future. Atlassian has already made that direction clear: Forge is becoming the primary app platform, while Connect is moving through a phased end-of-support path for Jira and Confluence Cloud.
That is why this is more than a product update for us.
🥳 SLA Time and Report for Jira is now on Forge, and we see that move not as a technical checkbox, but as an important step for the future of the app and for the customers who rely on it every day.
For anyone who is new to the app: SLA Time and Report helps teams define, track, and report SLA and OLA performance in Jira. It is built for teams that need more than a static deadline field: flexible SLA rules, automated time tracking, alerts before breach, and reporting that helps explain what is happening across support, service, delivery, QA, and internal operations. On the Marketplace, the app is positioned around high-performance SLA and OLA management, flexible goal setup, escalation logic, and SLA reporting for Jira.
In simple terms, it helps teams answer questions like: Are we meeting commitments? Where do breaches start? Which queues, services, priorities, or teams are slipping? And what should we fix before a missed SLA becomes a customer issue?
This migration did not happen in a vacuum. Atlassian has publicly stated that Forge will become its only cloud app development platform over time, and that Connect support is being phased out in stages for Jira and Confluence. Phase 1 stopped new Connect app listings on the Marketplace from September 17, 2025. Phase 2 begins enforcement in March 2026 for updates via Connect descriptor changes. Phase 3, when Connect enters end of support, is planned for Q4 2026. Atlassian’s definition is also very clear: an app is considered a Forge app only when it exclusively uses Forge modules; apps that still include Connect modules are still treated as Connect apps.
So for vendors, the question is no longer “Should we pay attention to Forge someday?” It is “How do we move in a way that is safe for customers, practical for the team, and aligned with the platform we build on?”
A simple way to think about it is this:
Connect gave vendors a lot of freedom. You could choose your own stack, host the app yourself, and manage much more of the surrounding operational model on your side. Atlassian’s own docs describe Connect as a framework where the vendor controls the tech stack, infrastructure, and security implementation, while the app operates remotely over HTTP.
Forge shifts much more of that foundation onto Atlassian’s platform. Atlassian describes Forge as its cloud app platform where infrastructure is provisioned, managed, monitored, and scaled automatically by Atlassian. In other words, the app becomes much more aligned with the platform it extends.
For customers, that difference is not abstract. It changes the trust conversation. It changes procurement conversations. It changes how future-ready an app looks. And it changes whether a vendor is investing in the direction Atlassian itself is investing in.
The first benefit is simple: future alignment. Atlassian is continuing to invest in Forge capabilities, and existing Connect apps can incrementally adopt Forge while keeping their existing features, installations, and reviews. Atlassian also highlights that Forge adoption gives apps access to newer integration points, Forge storage, Forge-hosted functions/UI, OAuth 2.0 REST APIs, GraphQL APIs, and future roadmap capabilities.
The second benefit is a stronger trust story. Forge’s privacy and security documentation frames the platform around protecting customers and applies when Atlassian provides Forge-hosted compute and storage. Atlassian also states that it has established contractual, technical, and organizational measures to help ensure Forge complies with GDPR, and notes that Forge, as part of the Atlassian Platform, has completed ISO 27001 and SOC 2 evaluation processes.
The third benefit is better fit for enterprise requirements. Atlassian’s data residency documentation says that when apps use persistent Forge hosted storage, that data can align with the admin’s chosen location and move together with the Atlassian app data. Atlassian’s Runs on Atlassian program also exists specifically to help customers identify Forge apps that are better suited to strict privacy requirements, especially where apps use Atlassian-hosted compute and storage and support matching data residency.
The fourth benefit is operational simplicity over time. Atlassian explicitly lists immediate app updates for customers, for non-admin-approved updates, as one of the advantages of adopting Forge from Connect.
Large enterprises usually do not evaluate apps only by features. They evaluate them by risk, transparency, operational fit, and long-term viability.
That is why Forge matters beyond engineering teams. When an enterprise customer asks questions about hosting, platform direction, data handling, regional requirements, compliance posture, and long-term supportability, the migration conversation becomes a business conversation, not just a development one. Atlassian’s own Forge materials increasingly position the platform around privacy, security, data residency, and enterprise trust signals. In practice, that makes Forge migration especially relevant for customers with formal procurement or security review processes.
This does not mean every app becomes magically “enterprise-ready” just by moving. Vendors still need to build responsibly, communicate clearly, and make product choices that respect customer needs. But Forge gives a much stronger foundation for that conversation than waiting on an aging model while Atlassian’s roadmap keeps moving forward.
For us, the move to Forge was about three things.
First, platform reality. Atlassian has made its direction public, and we wanted SLA Time and Report for Jira to move with that direction, not behind it.
Second, customer trust. Our app is used in workflows where deadlines, response targets, escalations, and service visibility actually matter. When teams use an SLA app, they are not buying decoration. They are buying confidence: confidence that commitments are measured correctly, risk is visible early, and the app they depend on is evolving in the right ecosystem direction.
Third, long-term product value. Atlassian’s Forge adoption path makes it possible for existing Marketplace apps to move forward while keeping their listing continuity, installations, and reviews. That matters because migration should feel like progress for customers, not disruption. Atlassian staff have also clarified publicly that vendors can use staged migration approaches, and that admins may need to click Update to receive the Forge version of an existing Marketplace app.
Moving SLA Time and Report for Jira to Forge is, for us, a practical investment in the next stage of the Atlassian ecosystem.
Yes, it is a platform migration. But more importantly, it is a signal: that we want the app to stay aligned with where Jira Cloud is going, to support customers with stronger trust and future readiness, and to keep building an SLA solution that is not only useful today, but credible for the years ahead.
If you are already using SLA Time and Report, this change is part of making the app more future-ready on Atlassian Cloud. And for teams that are still evaluating how to handle SLA management in Jira more effectively, this may also be a good opportunity to explore a solution that helps bring more structure to service commitments, more visibility into risks, and clearer reporting for day-to-day work. If you are currently reviewing your options, SLA Time and Report is worth a look.
Alina Kurinna _SaaSJet_
0 comments