Need to migrate schemas+content to an existing App (Dev ---> Stg)

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [ ] Performance issue
  • [x] Documentation issue or request

Current behavior

Does not Apply

Expected behavior

Does not Apply

Minimal reproduction of the problem

Does not Apply

Environment

App Name: oral-test-poc

  • [ ] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [x] Cloud version

Version: where do I look for this?

Others:
This is a request for information.
We are working on a Squidex App named “oral-test-poc” which we are currently revamping with the creation of new schemas/components and new content.
In addition to this we have another cloned App named “oral-surgery-cms” which is currently outdated with the above mentioned schemas and content. At some point in time we will need to migrate and OVERRIDE everything in the later App, which we will then use to feed a Production Application we are currently developing.

Given this said, we basically need to migrate all schemas/components and content to the second App, overriding what’s currently there and upgrading it with the other new schemas/components and content.

Could you please assist on how can we leverage this?

Thanks in advance for your assistance!

Hi,

there are 2 ways for that.

  1. Create a backup and create a request to restore the backup: https://docs.squidex.io/02-documentation/concepts/backups#how-to-restore-the-backup-in-the-cloud.

  2. Use the CLI for that: https://docs.squidex.io/02-documentation/developer-guides/automation-tools#synchronize-all-app-settings-beta

I would prefer option #2, because you can do it alone and it kind of overwrites your settings, but so far the CLI does not delete old contents. So if you want to be sure that two apps are identical you have to create a new one.

1 Like

Thanks for your response Sebastian!
Just a few questions for clearness:

  1. If we decide to migrate only schemas/components and NO content, same kind of migration approach applies?
  2. Regarding backup/restore approach, will this also override the later App GUIDs?

Our only concern, in whatever approach we would follow, is that the App we have in Staging is already connected to a Staging Web Application, and I’m not sure at this point if a migration of this type could break it, so it is something to evaluate.

Thanks!!

If you use the CLI, you can define, what you want to sync. So only schemas, contents, assets and so on.

Both approaches will keep the same IDs.

But this is independent from the chosen approach.