---
title: Migrate from v1 to v2
subtitle: How to use the Migration-Wizard
---

# Preparation

To upgrade an SCM-Manager from version 1 to version 2, some changes have to be made according the home directory of the SCM-Manager. So before you start, **make sure that you have an up to date backup of your SCM home folder!**

Before the migration process can be started, the last running version of SCM-Manager had to be (at least) 1.60. Data of older versions cannot be migrated automatically. If this is the case, you can stop version 1 and start a version 2 SCM-Manager (make sure that you have configured the same SCM home folder).
 
# Repository migration
 
When SCM-Manager starts for the first time, you have to choose how to migrate your existing repositories. The background of this is the following:

While in version 1 of SCM-Manager the repositories were stored in a directory according to their type (`git`, `hg` or `svn`) and their name, in version 2 the directory is independent of the type and name. Therefore a repository is no longer named with an arbitrary number of name parts devided by slashes (`/`), but it has a namespace and a name (both of which must not contain slashes). The namespace should be used to group your repositories (for example you can use this to distinguish between the types of repositories like *git* and *hg* like version 1 or to assign them to different projects or users).

To specify the new names (and namespaces), the SCM-Manager version 2 starts a migration wizard when it is first started with a home directory of a version 1 SCM-Manager. You can see an according message in the log:

```
2019-12-05 14:01:35.109 [main] [          ] INFO  sonia.scm.update.MigrationWizardModule - ==========================================================
2019-12-05 14:01:35.110 [main] [          ] INFO  sonia.scm.update.MigrationWizardModule - =                                                        =
2019-12-05 14:01:35.110 [main] [          ] INFO  sonia.scm.update.MigrationWizardModule - =             STARTING MIGRATION SERVLET                 =
2019-12-05 14:01:35.110 [main] [          ] INFO  sonia.scm.update.MigrationWizardModule - =                                                        =
2019-12-05 14:01:35.110 [main] [          ] INFO  sonia.scm.update.MigrationWizardModule - =   Open SCM-Manager in a browser to start the wizard.   =
2019-12-05 14:01:35.110 [main] [          ] INFO  sonia.scm.update.MigrationWizardModule - =                                                        =
2019-12-05 14:01:35.110 [main] [          ] INFO  sonia.scm.update.MigrationWizardModule - ==========================================================
```

You can open this wizard in an internet browser using the URL of your installation (eg. http://localhost:8080/scm/). 

![Migration Wizard](assets/migration-wizard.png)

In the figure you can see an example of the page. We tried to guess meaningful names, but for sure you want to make some changes here. Beside choosing new namespaces and names you have to select a migration strategy for each repository. The strategies are described on the page as follows:

|Strategy|Action|
|---|---|
|*COPY*	|Copy the repository data files to the new native location inside SCM-Manager home directory. This will keep the original directory.|
|*MOVE*	|Move the repository data files to the new native location inside SCM-Manager home directory. The original directory will be deleted.|
|*INLINE*	|Use the current directory where the repository data files are stored, but modify the directory structure so that it can be used for SCM-Manager v2. The repository data files will be moved to a new subdirectory 'data' inside the current directory.|
|*IGNORE*	|The repository will not be migrated and will not be visible inside SCM-Manager. The data files will be kept at the current location.|
|*DELETE*	|The repository will not be migrated and will not be visible inside SCM-Manager. The data files will be deleted!|

The probably most safe strategy (but also the most costly) is *COPY*. The old folder of the repository will be kept and all data will be copied to the new default folder (so this also is the default). *MOVE* and *INLINE* are more efficient. When you have a lot of repositories, maybe you will take the chance to clean them up and *IGNORE* or even *DELETE* old stuff.

# Migration of other data

For version 2 of SCM-Manager we introduced a new way to store data for repositories. We did our best to migrate old data like settings in plugins, so that nothing will be lost during update. What we did **not** do is to automatically install the new versions of your plugins. When you start your new instance, you will get a clean instance. You can install your new plugins from the administration page. Any plugin related data or settings will be migrated automatically.

# Manual plugin installation

If however you have to install plugins manually (for example because you cannot log in without the LDAP plugin), you can download them from the [plugins section](https://scm-manager.org/plugins/#categories) on our homepage. The download can be found in the "Releases" section of each plugin. Just store the `smp` file in the `plugin` directory of your SCM home and restart your server.

# Huge number of repositories

If you have more than 100 Repositories to migrate, you may have to adapt some configuration and increase the limit of jetty form keys. You can do this by setting the `maxFormKeys` and `maxFormContentSize` of the webapp in `conf/server-config.xml`. You have to add the keys to the `WebAppContext` with the id `"scm-webapp"` e.g.:

```
<New id="scm-webapp" class="org.eclipse.jetty.webapp.WebAppContext">
  <Set name="contextPath">/scm</Set>
  <Set name="war">
  <SystemProperty name="basedir" default="."/>/var/webapp/scm-webapp.war</Set>
  <!-- disable directory listings -->
  <Call name="setInitParameter">
    <Arg>org.eclipse.jetty.servlet.Default.dirAllowed</Arg>
    <Arg>false</Arg>
  </Call>
  <Set name="tempDirectory">
    <SystemProperty name="basedir" default="."/>/work/scm
  </Set>
  <!-- Set max form keys -->
  <Set name="maxFormContentSize">1000000</Set>
  <Set name="maxFormKeys">5000</Set>
</New>
```

The value for `maxFormKeys` should be the count of your repositories * 3 + 10. The `maxFormContentSize` depends on the length of your repository namespace and name, but you should be safe with repository count * 100.
