Atlassian Connect is approaching its final chapter (Connect EOS).
Atlassian has officially extended the Connect End of Support (EOS) date to January 31, 2027, giving Marketplace partners and developers a little more time to complete their migration to Forge. However, the extension should not be viewed as a reason to delay.
Several important Connect milestones have already passed. New Connect apps are no longer accepted on the Atlassian Marketplace, and Atlassian has made it clear that all new extensibility capabilities will be delivered on Forge. After January 31, 2027, Connect will no longer evolve alongside the Atlassian platform, with Atlassian only addressing critical security vulnerabilities.
For Marketplace vendors that still have Connect apps — or Forge apps that still contain Connect modules — the question is no longer whether to migrate, but how to complete the transition with minimum risk to customers and product development.
Why Connect EOS Matters More Now
The deadline itself is only part of the story.
Atlassian has already started making the transition more visible to customers.
Since July and August 2026, Atlassian has been rolling out Connect EOS messaging on the Connected Apps administration page. Depending on an app’s migration status, customer admins may now see information or warning banners explaining that the app is still using a platform that will become unsupported.
Atlassian has also started direct outreach to Marketplace vendors through ECOHELP tickets. This outreach specifically targets:
Connect apps with no Forge manifest
Forge apps that still contain Connect modules
Vendors are being asked to confirm their migration plans and work toward completing migration before January 31, 2027.
This means Connect EOS is no longer only a technical roadmap item.
It is increasingly becoming a customer communication, product continuity, and Marketplace positioning issue.
If customers see that an app is still running on Connect but cannot find a clear migration plan, they may start asking questions about long-term support, security, and compatibility.
What Happens After January 31, 2027?
Connect applications are not expected to suddenly stop working on February 1.
However, Atlassian has explicitly warned that Connect will not remain in a stable, steady state after EOS.
As Jira, Confluence, and the wider Atlassian Cloud platform continue to evolve, compatibility gaps between the platform and Connect applications are expected to grow. Connect capabilities may also be deprecated with shorter notice.
Over time, this can lead to:
Increased compatibility issues
Unexpected application breakages
Greater maintenance effort
Difficulty supporting new Atlassian functionality
Increased security and compliance concerns
A poorer experience for Marketplace customers
Atlassian therefore recommends that partners should not plan to maintain applications on Connect as a long-term strategy after EOS.
So what should Marketplace vendors do now?
1. Identify How Much Connect is Still in Your App
The first step is to understand your current architecture.
Not every application falls into the same category.
Your app may be:
Fully built on Connect
Using Forge while still retaining several Connect modules
Mostly migrated, with only a few Connect dependencies remaining
Running remote services that need to be reconsidered during migration
Already on Forge but still requiring additional work before Connect can be completely removed
Before estimating the migration, map out:
Connect modules currently in use
Authentication and authorization
Remote backend services
Webhooks and events
Data storage
External API integrations
UI modules
Scheduled processes
Customer data migration requirements
This assessment gives you a much more realistic picture of migration scope than simply treating the project as a framework rewrite.
Atlassian has also introduced an adoption-status CLI command that analyzes a Forge manifest and helps identify completed migration requirements and remaining work.
2. Decide Your Migration Strategy
A Connect-to-Forge migration does not necessarily need to happen in one large release.
Atlassian supports an incremental migration approach, allowing vendors to introduce Forge into an existing Connect application and progressively replace Connect components.
For many established Marketplace apps, this can significantly reduce risk.
A practical migration plan could look like:
Phase 1 — Assessment
Review the current Connect architecture, dependencies, Forge equivalents, and potential blockers.
Phase 2 — Introduce Forge
Adopt a Forge manifest and prepare the application for incremental migration.
Phase 3 — Move compatible modules
Migrate modules where Forge equivalents are already available and stable.
Phase 4 — Address complex components
Review backend services, storage, integrations, or features that cannot be migrated one-to-one.
Phase 5 — Test and validate
Verify functionality, performance, permissions, data integrity, and upgrade behavior.
Phase 6 — Remove remaining Connect dependencies
Complete the transition and validate the final Forge architecture.
The exact approach depends heavily on the architecture and maturity of each app.
3. Communicate Your Migration Plan to Customers
Technical migration is only one part of the transition.
Marketplace vendors should also proactively communicate what customers can expect.
Atlassian now provides the connectToForgeMigration module, which allows vendors to declare:
Whether they plan to migrate before EOS
A URL containing their migration plan
For Jira and Confluence apps that have adopted a Forge manifest, this information can be displayed directly to administrators in the Connected Apps experience.
A simple customer-facing migration page can explain:
Whether the app will move to Forge
Expected migration timeline
Whether customers need to take any action
Whether functionality will change
How customer data will be handled
Where customers can follow future updates
Clear communication can be just as important as the technical migration itself.
Customers do not necessarily expect a migration to already be finished — but they will increasingly expect vendors to have a plan.
4. Don't Treat Forge as a One-to-One Rewrite
One common mistake is approaching migration as:
Connect code → equivalent Forge code → done.
In practice, Forge has a different development and hosting model.
A migration is a good opportunity to reconsider:
Which services still need a remote backend
Which workloads can move into Forge
Data storage architecture
Authentication flows
Permissions and scopes
Event-driven processing
External dependencies
Operational and monitoring requirements
In some cases, maintaining parts of an existing backend may still make sense.
In others, moving more functionality into Forge can simplify infrastructure and reduce long-term maintenance.
The goal should not simply be to reproduce the old architecture.
It should be to create an architecture that will remain maintainable as the Atlassian Cloud ecosystem evolves.
5. Build Enough Time for Testing
Migration estimates should not cover development alone.
Marketplace applications may already have hundreds or thousands of active installations. A migration that works in a development environment but creates issues for existing installations can become a serious customer problem.
Your migration plan should include time for:
Functional regression testing
Existing installation upgrade testing
Permission and scope verification
Data migration validation
Performance testing
Integration testing
Different Jira or Confluence configurations
Production monitoring after rollout
The closer migration work gets to the EOS deadline, the less room there is to address unexpected technical issues.
This is why the January extension should be treated as additional migration buffer rather than additional waiting time.
6. Prioritize Your App Portfolio
For vendors managing multiple Marketplace apps, migrating everything at once may not be practical.
Instead, categorize your portfolio.
Priority 1: High-value apps
Apps with significant customers, revenue, or strategic importance should be migrated first.
Priority 2: Maintainable apps
Apps with an active customer base but lower commercial priority can follow once the migration approach has been proven.
Priority 3: Apps to retire
For low-adoption or legacy applications, Connect EOS may be the right point to consider discontinuation rather than investing in a full migration.
Making these decisions early helps avoid spending the final months before EOS trying to migrate an entire portfolio simultaneously.
Start Now, Even If You Have Already Started Forge
A common misconception is that an app is already safe simply because Forge has been introduced.
However, Atlassian’s current outreach specifically includes Forge apps that still contain Connect modules.
So the relevant question is not:
“Does our app use Forge?”
It is:
“Can our app operate without Connect?”
If the answer is still no, there is migration work left to do.
Final Thoughts
January 31, 2027 may still feel several months away, but for Marketplace vendors managing mature applications, that is not a long migration window.
Architecture assessment, development, regression testing, customer communication, Marketplace releases, and production stabilization all take time.
The safest approach is to use the remaining period to:
Assess remaining Connect dependencies
Define a realistic migration roadmap
Communicate the plan to customers
Migrate incrementally where possible
Test thoroughly before removing Connect
Complete the transition with enough buffer before EOS
The Connect era is ending, but this transition is also an opportunity to modernize your application architecture and prepare your products for the next phase of Atlassian Cloud.
Need Additional Forge Migration Capacity?
If your team has Connect applications to migrate but limited Forge capacity, DS Solution can support your migration from the initial technical assessment through implementation, testing, and post-migration maintenance.
Our Atlassian development team works with Marketplace vendors on Connect-to-Forge migration, Forge app development, Cloud and Data Center app maintenance, and dedicated development support.
If you are unsure how much work remains in your current app, a good starting point is a technical review of your existing Connect architecture and migration scope.
