The 2023 “legacy app migration” post describes a CasaOS 0.4.4 transition, not a current universal migration workflow. IceWhale instructed users of 0.4.4 to rebuild legacy apps manually and users on older builds to update to 0.4.4-1 first.
Because CasaOS/ZimaOS app packaging has changed substantially since then, the historical update command should not be copied into a modern system just to migrate an app.
What the Old Migration Feature Did
The UI separated older application definitions from the newer Compose-based model and offered actions such as Rebuild and Export as Compose. The goal was to retain application settings while converting the app definition.
The Old 0.4.4-1 Update Command Is Historical
The source post included a one-off curl ... | sudo bash update path for users on CasaOS 0.4.3 and below. That was a version-specific bridge from 2023, not a safe evergreen command.
A 2024 reply already showed the problem: a user on a later CasaOS build no longer saw the same buttons.
Modern App Stores Use Newer Metadata Contracts
The current App Store v1 to v2 guide documents a newer store protocol with store.json, index.json, store-config.json and required app IDs.
That page is for app-store maintainers, but it shows why the old “legacy app” UI should be treated as a historical migration layer.
For a User Migration, Protect the App Data First
Before replacing an old app definition, record its image, ports, environment variables and host-volume paths. Back up persistent configuration/data, then recreate the app using the current store package or a reviewed Compose file.
The Docker app migration basics covers the container pieces that actually need to survive.
Bottom Line
The old Rebuild button was a CasaOS 0.4.4-era compatibility tool. Do not downgrade or run a historical update script to recover that exact menu. Preserve app data, export or reconstruct the Compose settings, then migrate into the current app model.
