Moving a project

1. 1On the Studio, open Account → Security → API tokens and make a token with write scope. A one-day token is enough.
2. 2Save your work, then run this in the project folder, with the address you sign in to the Studio at:
   WEBENTOR_API_TOKEN=… npx --package=@webentor/site webentor-site studio connect app.studio.example
   With pnpm, pnpm exec webentor-site studio connect … does the same.
3. 3It checks first and stops with a sentence if something is in the way. Otherwise it creates the project, pushes your published branch and your drafts, and the Studio finishes setting the project up from that push.

Goes: the whole history, the published branch, every draft/… branch (as drafts), the media in the repository, and the hosting written in webentor.cloud.json.

Stays: hosting credentials (you paste them on the Studio), and anything that is not in the repository, such as form submissions your site collected on your own computer.

1. 1In the project, open Settings → Take it with you and choose Export everything. Download the ZIP when it is ready.
2. 2The README in the ZIP starts with where the @webentor packages come from. Set that up first, then unpack it into a project: npx @webentor/site clone my-site-export.zip. Without it, npm looks for the package on npmjs.com and answers that it does not exist.
3. 3Start it with npm start. Publishing asks only for the token of each hosting target the project had.

Goes: the whole history and every draft, the media, the last built site, the form submissions with the files visitors sent (as CSV), the analytics counts (as CSV), and the hosting written in the repository.

Stays: hosting credentials, people and their roles, and your domains, which you point at wherever the site runs next.

1. 1On the other Studio, make an API token with write scope that expires in a day.
2. 2Here, open the project’s Settings → Repository and type the other Studio’s address under Move this project to another Studio. It is asked what it can take, and you see the answer beside your project before anything is created there.
3. 3Paste the token, type the project’s name to confirm, and enter the code we email you. The move then runs on its own: you can leave the page, and it shows how far it is when you come back. You can cancel it until it starts marking this copy read-only.

Goes: the whole history and every open draft with its title, review state and schedule, the media, the hosting written in the repository, the redirects, and the form submissions with their files (when the other Studio takes them).

Stays: hosting credentials, people and their roles (the page lists them afterwards, to invite), webhooks, the repository mirror, analytics, the activity log, and drafts that were already published or discarded. Edits nobody saved in the editor stop the move until somebody saves or discards them.

• Owners and admins open the team’s Move tab, type the other Studio’s address and read, for each project, whether it can go.
• A project the other Studio cannot take stays here and the report says why. The others go one after another; a project waiting its turn works as usual until its own move starts.
• Each project then needs the same steps as a single move, below.

1. 1On the new Studio, add the tokens its hosting targets ask for.
2. 2Verify each custom domain there. It asks for a new TXT record in your DNS.
3. 3Point the domain at the new Studio and check the site loads from there.
4. 4Form submissions keep arriving at the old copy until DNS has moved. Send the new ones across from the old project’s Settings → Repository, or export them.
5. 5Invite the people who worked on the project. Nobody is invited automatically.
6. 6Revoke the token you made for the move, then delete the old copy. It asks first while any of its domains still point at it, because deleting it then takes the site offline.