This was sad for those working in quarantined environments and needed to throw up prototype to set up a functional process tool. This was nice to have. We hope for viable options. Thanks

For anyone exporting a Spark app and wanting to continue developing it, I published a Copilot CLI conversion plugin that migrates the application into an Aspire + Microsoft Foundry architecture.

The skill inventories the app, coordinates the current Aspire and Microsoft Foundry skills, removes Spark-specific residue, and validates the converted application end to end.

Repository and installation instructions: https://github.com/spboyer/spark-to-aspire

For anyone using the remaining export window, I would treat exporting the repository and migrating the application as two separate jobs.

Before August 31, I would do the following for every existing Spark app:

1. Use … → Create repository, then open the repository and verify that the latest source files, assets, configuration examples, and recent changes are actually present.
2. Record the deployed app URL, repository URL, last known working state, and any external services the app depends on.
3. Search the exported code for llm(), spark.llm, spark.llmPrompt, model endpoints, and related environment-variable names. A page that still loads may still have broken AI functionality.
4. Keep replacement API keys in the deployment platform’s secret storage, not in the repository, and rotate any key that was accidentally committed.
5. Check data storage, authentication, permissions, and deployment separately. Creating a repository preserves the code, but it does not prove that those platform-managed parts have been migrated.
6. Preserve a rollback point before replacing the inference provider, then test success, timeout, rate-limit, authentication-error, and empty-response paths.

I wrote a more detailed Chinese checklist covering the export, dependency inventory, llm() search, provider replacement, and post-export verification here: How to export apps before GitHub Spark is deactivated on August 31

I have an existing deployed Spark.

The application and its persisted KV data were still working last week.
The frontend is still deployed, but Spark KV has now stopped working. spark.kv.keys() results in:
GET /_spark/kv → HTTP 404

As a result, the persisted application data no longer appears in the app.

localStorage is empty and IndexedDB contains no databases, so this appears to affect the Spark-managed KV backend.
GitHub's deprecation notice says deployed Spark apps will continue to work after the August 31 retirement.

I also no longer have access to the Spark UI to export the KV data or unpublish/delete the deployment. GitHub Support automatically closed my ticket.

Can someone from the Spark/runtime team confirm whether the KV store still exists and whether it can be recovered or temporarily reattached to the deployed application?

I would also like to remove the runtime after recovering the data.