Migrating projects between version control repositories

If your organization has changed Git hosting services, and you therefore need to migrate projects from one supported version control repository to another, we recommend you follow this high-level process:

  1. Perform pre-migration setup.

  2. Run the project migration script.

  3. Perform post migration cleanup.


  • Update the Anaconda Enterprise config map with the information required to connect to the external version control repository.

  • To run the project migration script, you’ll need Administrator access to a command line tool that can run bash or Python scripts on the master node of the Anaconda Enterprise cluster.

  • You’ll also need the Postgres database password, origin Git host token/password, and destination Git host token/password.

Pre-migration setup

  1. If you haven’t already done so, install the version of conda provided with the Anaconda Enterprise installer on the master node:

    bash anaconda-enterprise-5.3.1-56.gf54c3abad/installer/conda-bootstrap-4.5.12
  2. After conda is finished installing, login to the terminal again.

  3. Install git, using the command that’s appropriate for your environment:

    On RHEL/CentOS: yum install git

    On Ubuntu/Debian: apt install git

  4. Use the following command to create the conda environment:

    conda create --name migrate --file anaconda-enterprise-5.3.1-56.gf54c3abad/environment.txt
  5. Temporarily disable reverse proxy authentication by adding the following key-value pair to the git section of the anaconda-enterprise-anaconda-platform.yml file used to configure the platform to use an external version control repository:

    reverse-proxy-auth: false
  6. Run the following command to restart the associated pod on the master node:

    kubectl delete pod -l 'app=ap-git-storage'

Using the migration tool

Running this script creates a local origin repository containing all of the Anaconda Enterprise projects that were stored in the existing remote origin repository, then pushes the local origin repository to the new remote destination repository.

  1. On the master node of the Anaconda Enterprise cluster, copy the migrate_projects.py script from the location where you saved the Anaconda Enterprise installer tarball using the following command:

    sudo cp migrate_projects.py /opt/anaconda
  2. Create a user mappings file that maps Anaconda Enterprise user IDs to Git user IDs. This is a colon-separated text file where the first field is the AE user name, and the second field is the corresponding Git user name. For example:





Either create or place this file in the same directory as the migrate_projects.py script (/opt/anaconda). You’ll refer to this file by name when you run the migration script in the next step.

  1. Cd into /opt/anaconda and run the following command to begin migrating your projects, replacing all placeholder values with actual values.

migrate_projects.py --postgres-host localhost --origin-api-url <https://localhost:8443/> --origin-username root --dest-api-url <https://githost.domain.com/> --dest-username root --dest-organization <org_name> --dest-user-mappings <user-mappings.txt> --force-migrate --parallel 4


Type --help to view information about the command options and arguments.

  1. Enter your Postgres database password when prompted.

  2. Enter your origin Git host token/password when prompted.

  3. Enter your destination Git host token/password when prompted.

Post-migration cleanup

After the script finishes migrating the projects, re-enable reverse proxy authentication by editing the key-value pair you previously added to the git section of the anaconda-enterprise-anaconda-platform.yml file, so it looks like the following:

reverse-proxy-auth: true


If you do not re-enable reverse proxy authentication, Anaconda Enterprise will not work.

To verify that the new repository is being used by Anaconda Enterprise, edit an existing project and commit your changes to it.


If you’ve migrated to https://github.com, whenever a user is added to a project as a collaborator, they’ll be sent an invitation to collaborate via email. They’ll need to accept this invitation to be able to commit changes to the repository associated with the project. This does not apply to Github Enterprise.