# How to move projects between different RenkuLab Deployments

**URL:** <https://renku.discourse.group/t/how-to-move-projects-between-different-renkulab-deployments/215>\
**Category:** FAQ\
**Created:** [27 November 2020 16:34 UTC](https://renku.discourse.group/t/how-to-move-projects-between-different-renkulab-deployments/215 "2020-11-27T16:34:16Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![lorenzo](https://avatars.discourse-cdn.com/v4/letter/l/4da419/32.png) [@lorenzo](https://renku.discourse.group/u/lorenzo)\
**Post date:** [27 November 2020 16:34 UTC](https://renku.discourse.group/t/how-to-move-projects-between-different-renkulab-deployments/215/1 "2020-11-27T16:34:16Z")

</div>

We have users interacting with two or more Renkulab deployments, and it’s occasionally needed to move a project between them.  
Here is a recap of what you should do. The explanation is rather verbose, but it’s actually only a few commands.

Depending on a few factors (e.g. amount of data in the project, accessibility of the deployments, etc.), it’s possible to choose between 2 alternatives:

1. Start an Interactive Environment on the source deployment.
2. Clone the project locally and push it.

Depending on which technique you choose, the first steps are different.

### Case 1 - Interactive Environment

- Start a new interactive environment in the project you want to migrate. Optional: you can turn on the option to `Automatically fetch LFS data`. Depending on the amount of LFS data, that may extend the startup time.

- Verify that the lfs files are checked out properly by typing

### Case 2 - Local environment

- Verify you have both `git` and `git lfs` installed locally

```auto
git lfs

```

- Log in the source deployment, go to the project you want to clone, and select the “Settings” tab. Copy and execute the clone command locally in an empty folder. **TIP** : If you have the `renku` package installed in your command line, you should prefer the `renku clone` solution over `git clone`.  
This step may require some time, depending on the amount of data and your internet connections.

### Common steps

- It’s possible to push the content directly to the target deployment without first creating an empty project. It’s important to push to a valid combination of namespace/project name though.  
The target url will have the following structure  
`https://<deployment_gitlab_url>/<namespace>/<project_name>`.  
How do you find the correct values?

- **OPTIONAL** : if you need to push **all** the branches, you need to track and fetch them

- Add the target URL as a new remote:

- Push the content to the new remote. If you need to push only the current branch, let’s say `master`, you can execute:

- Depending on the amount of data and the connection, the last step may require some time. When the command terminates, you can start working with your project on the target deployment.  
**TIP** : Be aware that user permissions (e.g. external collaborators or group permissions) aren’t preserved in the target deployment. You will need to add them manually. You will also need to activate the knowledge graph. You will see a warning the first time you open the cloned project. Just click on the “Activate Knowledge Graph” button.

### Non-renku projects

Do you want to import projects from outside Renku? The steps are similar, but you may want to Renku-ize the project.  
Our documentation can guide you through the necessary steps: [https://renku.readthedocs.io/en/latest/tutorials/02\_migrating\_to\_renku.html#renku-ize-your-project-with-renku-cli](https://renku.readthedocs.io/en/latest/tutorials/02_migrating_to_renku.html#renku-ize-your-project-with-renku-cli)