Forge versus Connect: When Is the Right Time to Switch

Why this question matters now

Atlassian’s cloud ecosystem is evolving rapidly – and so are the demands placed on app developers.

At the heart of this transformation is Forge, Atlassian’s serverless app platform. Initially viewed as a “new” alternative, Forge has now matured into an established and actively promoted technology.

At the same time, traditional Connect apps are facing increasing pressure – not only from Atlassian’s push to encourage migration, but also from very practical concerns: Connect apps require dedicated hosting infrastructure, involve more maintenance, and often fall short of meeting modern compliance requirements.

If you want to remain competitive in the long term, it’s time to ask: Is it time to migrate – and if so, when?

Forge vs. Connect – a brief comparison

Let’s quickly recap the key differences between the two platforms:

Atlassian Connect

Traditional app model with custom server infrastructure
Offers high flexibility and full control over backend logic
Hosting, maintenance, security and scalability are the app vendor’s responsibility
Technologically open – can be built in any language (PHP, Java, Python, etc.)

Atlassian Forge

Serverless platform fully integrated into Atlassian’s infrastructure
No custom servers required, no maintenance – automatic scaling included
Standardized security models, built-in data residency, performance optimization
Native UI elements with Custom UI for more flexibility
Primarily built for JavaScript/TypeScript (restricted tech stack)
Lower operational costs thanks to Atlassian-hosted infrastructure

When Connect still makes sense

Despite the advantages of Forge, there are still scenarios where Connect may be the better short- or mid-term choice:

Your app is mature, has a large user base, and a stable codebase – migration pressure may be low.
You rely on features Forge doesn’t yet support (e.g., specific REST APIs, web triggers, or persistent background processes).
Your app has infrastructure or integration requirements Forge cannot fulfill.
Your development team prefers non-JavaScript languages for technical or legacy reasons.

When switching to Forge makes sense

On the flip side, there are strong incentives for migrating to Forge – especially when:

Security and compliance are mission-critical (GDPR, data residency, industry-specific requirements).
You want to reduce hosting costs and operational overhead.
You need improved performance and reliability through deep Atlassian integration.
You’re targeting higher market visibility with labels like “Runs on Atlassian”.

Forge is especially beneficial for new apps or for those migrating early – offering scalability, architectural clarity, and full alignment with Atlassian’s cloud strategy.

Ideal scenarios for Forge today

Data-heavy apps benefit from automatic scaling
Global apps with strict local data residency requirements
Jira/Confluence UI apps that rely on native components and optimized performance
Highly regulated industries (finance, healthcare) that require a hardened security environment
Startups and small teams looking to minimize infrastructure and DevOps burden

Migration: More than just a technical step

Moving from Connect to Forge isn’t just a technical decision – it’s a strategic investment with long-term impact.

Even though the benefits are clear, many teams hesitate to start. That may be due to technical limitations (see above), but often uncertainty is the real barrier.

The good news: a structured, iterative approach helps reduce complexity and guides your team step by step.

Let’s break it down:

Inventory & Feature Mapping

Which existing Connect features can already be built on Forge?
Are there gaps (e.g., persistent storage, webhooks)?
Which features are mission-critical, and which are nice to have?

Choosing a Migration Path

Re-engineering: Ideal for smaller apps or legacy-heavy code. Start fresh on Forge.
Hybrid strategy: Keep the existing Connect app live while gradually replacing parts with Forge components.
Greenfield: Build a new Forge app from scratch with a different scope or audience (e.g., new MVP, evolved use case).

Prototype & Sandbox Testing

Use the Forge dev environment to prototype key functionality.
Test performance, permission scopes, and UI behavior in real-world scenarios.

Stakeholder Involvement

Communicate early and transparently – especially with privacy-critical apps.
Gather feedback from users: What’s essential? What concerns exist?

Pilot Phase & Iterative Rollout

Test the Forge app with selected customers or internal teams.
Run Connect and Forge in parallel for a transition period.
Document lessons learned to inform future migrations.

Best Practices for a Smooth Transition

Avoid 1:1 porting: Use the opportunity to rethink architecture and future-proof the app.
Follow the Forge roadmap: Atlassian releases new features regularly – plan for phased implementation.
Leverage Forge’s security tools: Use built-in scopes, function boundaries and permission models.
Plan for certification: Mid-term, consider criteria for “Cloud Fortified” and “Runs on Atlassian” badges – they’re increasingly important for enterprise adoption and visibility.

Conclusion

Forge isn’t just a new framework – it’s the future of Atlassian app development. While Connect may still be appropriate in some edge cases, Forge is rapidly becoming the standard. Teams that act early and plan strategically will benefit from lower operating costs, higher security standards, seamless Atlassian Cloud compatibility, and better visibility on the Marketplace.

Is your team planning a move to Forge? Do you want to modernize your app strategy? Our experienced Atlassian development teams can support you with architecture, development, and certification.

Forge versus Connect: When Is the Right Time to Switch – and for Whom?