Need help: Migrating 120+ apps with module dependencies without Source Control

💬 App Building
1

Hi everyone,

We are currently in the process of migrating our Retool environment (Self-Hosted Enterprise to Cloud Business), but we have run into a major blocker due to the sheer volume of apps and complex module dependencies.

Here are the main issues we are facing:

1. How to efficiently migrate 120+ apps without Source Control?

  • We have over 120 apps that need to be migrated.

  • Because the target account is on a plan without Source Control enabled, we are forced to export and import them manually via JSON/ZIP.

  • Doing this manually for 120+ apps is extremely time-consuming and prone to errors. Is there any CLI tool, script, or recommended workflow for bulk migration in this scenario?

2. Resolving Module UUID mismatch / Broken imports

  • Almost all of our apps rely on shared Modules, and some modules also contain actions/buttons referencing other app pages.

  • When exporting/importing via JSON, the Module UUIDs break or do not match across the environments.

  • Because of this circular dependency (App -> Module -> App/Page UUID), Retool throws errors during JSON/ZIP import, preventing us from importing the modules or the main apps.

Questions for the community:

  1. Has anyone successfully migrated a large number of interdependent apps/modules without Source Control?

  2. What is the best way to resolve broken Module UUID references during JSON imports without having to manually edit 120+ JSON files?

Any advice, scripts, or workarounds would be greatly appreciated!

1 Like
4

120 apps via manual JSON/ZIP export sounds rough, especially with the UUID mismatches on top. Are you checking those exports for hardcoded API keys or tokens before they land in the new account?

5

Hey @Chaewon_Lim! Welcome to the community and thanks for reaching out. :slightly_smiling_face:

This is definitely a challenging problem - we have an internal utility for handling the opposite scenario, but I'm not aware of anything to specifically help migration from on-prem to Cloud. :thinking:

That said, I think there's probably a solution to the UUID issue that you're seeing. In theory, you should be able to write a script that POSTs app JSON files - not ZIP - to /api/pages/createPage, starting with any shared modules. The important thing about this endpoint is the fact that it attempts to match modules by both UUID and name.

If you're interested in talking through this solution or even working on a proof of concept together, feel free to join our scheduled Office Hours!

6

found a workaround that worked for us (120+ apps, modules/resources included).

We ended up migrating manually with a UUID-mapping approach instead of relying on source control:

  1. Download all app code from the source instance locally (we used source control on the source side, pushed to GitHub, then cloned).

  2. Scan the local code to collect every module/resource UUID referenced by the apps.

  3. Recreate the matching modules/resources on the target instance.

  4. Extract the new UUIDs generated on the target.

  5. Build a mapping table: source UUID → target UUID.

  6. Use that mapping to replace all UUIDs in the downloaded app code with the target ones.

  7. Import the rewritten apps into the target instance one by one.

For steps 2/5/6 (extracting UUIDs, building the mapping, doing the replacement across all files), we used a coding agent (Claude Code, in our case) to do the grunt work — any capable coding agent should handle this fine.

This avoided broken module/resource links entirely across the whole batch. You'll still want to QA each app in the new environment afterward, but the links themselves came through clean.

7

Nice! Glad to hear it. :+1: