Is there an announced retirement date for the legacy storage APIs previously provided through @forge/api?

Forge
,
1

Hi,

We are currently migrating our Forge apps from the legacy storage APIs to @forge/kvs.

I have reviewed CHANGE-2924, CHANGE-3252, the current Forge Storage documentation, and related Community discussions. However, I have not been able to find any official information regarding the actual retirement timeline of the legacy storage implementation.

From the information available, I understand that:

- New development should use @forge/kvs.

- References to the legacy storage APIs have been removed from the current Storage documentation.

- Atlassian staff have stated that @forge/storage is no longer a supported package.

However, our production apps are still successfully using the legacy storage implementation today.

Could Atlassian clarify the following points?

- Has a retirement/removal date for the legacy storage implementation been defined?

- Can existing apps continue to use the legacy implementation until that date?

- Will Atlassian provide a notice period before the legacy storage implementation is retired?

- Is there any published roadmap or timeline regarding the final shutdown of the legacy storage backend?

We understand that migration to @forge/kvs is recommended and are actively planning our migration. However, we would like to better assess the urgency and operational risk by understanding the expected retirement timeline of the legacy storage implementation.

Thank you for your clarification.

2

Hi @tsu.miyazaki,

The published dates have already passed. CHANGE-2924 opened a 6-month deprecation on 2025-12-01, per the deprecation policy, and announced that after 2026-06-01 the GraphQL storage endpoints return 410 Gone. CHANGE-3252 then removed storage from @forge/api on 2026-06-22, the 8.x line has no such export.

Your prod is the odd part.

The old storage module calls /forge/entities/graphql under the hood, so by the letter of CHANGE-2924 it should already be failing. It isn’t, which means the in-app path hasn’t actually been cut yet. Undocumented grace period. No date. The notice period has been served, so it can close without another announcement.

Bump to 8.x and the build breaks on that import. I’d do the move to @forge/kvs now anyway. For a firm answer on the grace period, ECOHELP is where CHANGE-2924 itself points at-risk apps.

3

Hi @tsu.miyazaki,

I’m part of the storage team and would like to thank you for working on the migration to the new forge kvs package. Please find the answer for each of your questions below:

Has a retirement/removal date for the legacy storage implementation been defined?

In order to reduce impact on the end customer we decided to keep it running for longer, but support is over and apps should migrate immediately.

Can existing apps continue to use the legacy implementation until that date?

Existing apps can continue to use it, but they may stop working/experience failures and are exempt from receiving active support.

Will Atlassian provide a notice period before the legacy storage implementation is retired?

The notice has already been provided and the date has passed, no new noticed will be issued about this matter.

Is there any published roadmap or timeline regarding the final shutdown of the legacy storage backend?

The continuity that is currently active is offered as a minimum effort to align with out DFTC core value, understanding that old-version upgrades fall outside the direct control of app-vendors

Thank you @Mihai_leanzero for jumping in as well!

If you got any more question please let me know!

Best,
Rodolfo

4

Hi @RodolfoCandido,

Thank you for the detailed clarification, and thanks @Mihai_leanzero as well.

My understanding is:

- The legacy storage implementation is currently still running as an extension period.

- Support for it has already ended.

- No additional retirement notice will be provided.

- Existing apps should migrate to forge/kvs as soon as possible.

This answers my question and helps us plan our migration work.

Thank you for the clarification and for keeping the legacy implementation available during the transition period.

Best regards,

Tsubasa Miyazaki