diff --git a/scm-core/src/main/java/sonia/scm/migration/UpdateStep.java b/scm-core/src/main/java/sonia/scm/migration/UpdateStep.java
index eaa6d8d549..ed5f60a630 100644
--- a/scm-core/src/main/java/sonia/scm/migration/UpdateStep.java
+++ b/scm-core/src/main/java/sonia/scm/migration/UpdateStep.java
@@ -3,11 +3,80 @@ package sonia.scm.migration;
import sonia.scm.plugin.ExtensionPoint;
import sonia.scm.version.Version;
+/**
+ * This is the main interface for data migration/update. Using this interface, SCM-Manager provides the possibility to
+ * change data structures between versions for a given type of data.
+ *
The data type can be an arbitrary string, but it is considered a best practice to use a qualified name, for
+ * example
+ *
+ * com.example.myPlugin.configuration for data in plugins, or
+ * com.cloudogu.scm.repository for core data structures.
+ *
+ *
+ * The version is unrelated to other versions and therefore can be chosen freely, so that a data type can be updated
+ * without in various ways independent of other data types or the official version of the plugin or the core.
+ * A coordination between different data types and their versions is only necessary, when update steps of different data
+ * types rely on each other. If a update step of data type A has to run before another step for data type
+ * B, the version number of the second step has to be greater in regards to {@link Version#compareTo(Version)}.
+ *
+ * The algorithm looks something like this:
+ * Whenever the SCM-Manager starts,
+ *
+ * - it creates a so called bootstrap guice context, that contains
+ *
+ * - a {@link sonia.scm.security.KeyGenerator},
+ * - the {@link sonia.scm.repository.RepositoryLocationResolver},
+ * - the {@link sonia.scm.io.FileSystem},
+ * - the {@link sonia.scm.security.CipherHandler},
+ * - a {@link sonia.scm.store.ConfigurationStoreFactory},
+ * - a {@link sonia.scm.store.ConfigurationEntryStoreFactory},
+ * - a {@link sonia.scm.store.DataStoreFactory},
+ * - a {@link sonia.scm.store.BlobStoreFactory}, and
+ * - the {@link sonia.scm.plugin.PluginLoader}.
+ *
+ * Mind, that there are no DAOs, Managers or the like available at this time!
+ *
+ * - It then checks whether there are instances of this interface that have not run before, that is either
+ *
+ * - their version number given by {@link #getTargetVersion()} is bigger than the last recorded target version of an
+ * executed update step for the data type given by {@link #getAffectedDataType()}, or
+ *
+ * - there is no version number known for the given data type.
+ *
+ *
+ * These are the relevant update steps.
+ *
+ * - These relevant update steps are then sorted ascending by their target version given by
+ * {@link #getTargetVersion()}.
+ *
+ * - Finally, these sorted steps are executed one after another calling {@link #doUpdate()} of each step, updating the
+ * version for the data type accordingly.
+ *
+ * - If all works well, SCM-Manager then creates the runtime guice context by loading all further modules.
+ * - If any of the update steps fails, the whole process is interrupted and SCM-Manager will not start up and will
+ * not record the version number of this update step.
+ *
+ *
+ *
+ */
@ExtensionPoint
public interface UpdateStep {
+ /**
+ * Implement this to update the data to the new version. If any {@link Exception} is thrown, SCM-Manager will not
+ * start up.
+ */
void doUpdate() throws Exception;
+ /**
+ * Declares the new version of the data type given by {@link #getAffectedDataType()}. A update step will only be
+ * executed, when this version is bigger than the last recorded version for its data type according to
+ * {@link Version#compareTo(Version)}
+ */
Version getTargetVersion();
+ /**
+ * Declares the data type this update step will take care of. This should be a qualified name, like
+ * com.example.myPlugin.configuration.
+ */
String getAffectedDataType();
}