Transition process from one source code hosting system to another

Transition process from one source code hosting system to another

I have earlier written about disadvantages of scattered source code hosting and how a consolidated source code hosting platforms help in the case. In this blog post I'm going to cover a transition process from one source code hosting system to another. Similar process can be used to migrate even multiple systems, which is the case in scattered source code hosting environment. The process has been implemented successfully with mission-critical systems that have thousands of active users.

The process is presented in the graph above. I have mapped the phases to correspond to technology adoption lifecycle to visualize the adoption and transformation from one system to another. In large organizations, transition needs to be done gradually, as not everyone is ready to switch instantaneously. The time span of migration varies from months to a year depending on amount of users and willingness to accept change. It is common that some projects tend introduce change easily as others lag behind and take only bullet-proof solutions into use. The transition process has four phases:

  1. Introduction of the new system
  2. Halting growth of existing systems
  3. Voluntary migration, and
  4. Forceful migration

I will cover each step in more detail below.

1. Introduction of new system

Every change needs to be attractive to its users. In the transition process we start by introducing and announcing the new system to users. We can open beta signups or select beta users that migrate to use the new system for a limited amount of users. Appropriate amount varies case-by-case. As a rule of a thumb, more than 10% of the total users is too much. The purpose of this phase after all is to get first feedback and find any teething troubles there might be.

2. Halting growth of existing systems

As we have gathered enough feedback from the early adopters, and fixed any teething troubles, we can move forward with the transition. The second phase is to halt the growth of existing systems available. This practically means disabling creation of new projects in existing systems and at the same time setting the new system publicly available, so that every new project is created to the new system. It is essential in this phase of transition to announce the availability of the new system, in order to create knowledge.

3. Voluntary migration

After the new system is up and running in a stable manner and existing systems sealed, you should leave time for teams to voluntarily migrate their projects. This way teams can find a suitable time slot for migration, and be more willing to migrate their projects. Length of the voluntary migration phase should depend on the willingness of projects to migrate. If it seems that projects are reluctant, the length can be reduced.

4. Forceful migration

The last phase should be commenced after enough time is given for projects to migrate voluntarily. Forceful migration should be done gradually, meaning that we set a certain pace and pick the projects to be migrated beforehand. The information needs to be publicly available to each project, as it allows projects to have a say to the schedule.

Conclusion

By using the transition process described above even systems with thousands of users can be transitioned to a new one. The transition is mostly about planning a good schedule, communicating it thoroughly, and having the plan fully visible. Visibility is important because it allows projects to match the transition to their own schedule. Another important aspect is the support for migrating projects. This means having necessary documentation, tools and training available.

If you would like to hear more, how we have helped organizations to transition from other systems to Deveo, please stay in touch. Contact us.

Seamless software development.

Code management and collaboration platform with Git, Subversion, and Mercurial.

Sign up for free
comments powered by Disqus