Steps for Migrating Code Between Version Control Tools

Code migration can be tricky if you’re not prepared. Follow these steps for a worry-free migration.

Almost all source code contains some format of delicate information, whether it be configuration-related information such as database credentials or information on how the web application functions, such as a web template.

If such information is disclosed, this information potentially could be used by an attacker to discover logical flaws and escalate into a successive chain of attacks. These include attacks such as SQL injection, database takeovers, cross-site scripting, remote code execution and, sometimes distributed denial of service.

To achieve solution for conducting a risk-free and systemic migration, we need to plan three stages for the code migration process: pre-migration, migration and post-migration.

Key Considerations During Pre-Migration

• License cost
• Administration cost
• Developer productivity
• Security of data
• Training of team
• Total cost of ownership
• Knowledge on all connected tools with application lifecycle management
• Agile adoption policies and CI practices
• Team structure – distributed or co-located?
• File types – Do you have large binary files?
• Need file locks?
• Users have the appropriate permissions to fetch and push
• Builds are successful, and all your tests are passing

Key Considerations or Challenges During Migration

• Test environment
• Capacity planning
• Compute capacity
• Benchmark the current version control system
• Network connectivity
• Access between source and target servers
• Load testing
• Access control
• Aim to migrate over a weekend when nobody needs to check-in

Key Considerations During Post-Migration

• Data integrity verification
• Data size check
• Automated acceptance testing and reporting
• Dependencies are intact and build doesn’t break
• Link between files and folders is not broken
• Load testing
• Backup and sync jobs

Moving to Distributed Version Control from Centralized Version Control

When migrating code from a centralized version control system such as Apache Subversion (SVN) to a distributed version control such as GIT, here are the steps to take:

• Evaluate the tools and methods you’re planning to utilize
  • Build and test
  • Code reviews
  • Release management
• Select a branching strategy for GIT
  • long-lived feature branch
  • Short-lived feature branch
  • Bug fix branch
  • Dev branch

Reference: https://guides.github.com/introduction/flow/index.html

https://nvie.com/posts/a-successful-git-branching-model/

• Decide whether you want to migrate history; if yes, then determine how you will achieve this—you may need another third-party tool to resolve your task.
  • There are many tools available in market that can migrate a whole history of all branches from a centralized tool to GIT.
  • Almost all version control systems collect how files change between versions, including rename, merge and rollback. GIT version control tool stores versions as a snapshot of the entire repository.

• Retain your old version control system for a set time after migration.
  • During and after a migration, developers sometimes need access to the history in the old version control system, so you can’t just shut the old system down once you’ve migrated.
  • There should be some text file committed in GIT which should explain how/when the GIT branches were migrated from the old system and what all branches are migrated.

• Remove binaries and executables from source control.
  • You should avoid commit large binary files to a repository. Once they’ve been committed to a repository, they will remain in the repository history and in every upcoming clone.
  • Migrating to Git provides you the opportunity to remove these binaries from your codebase and instead use a package management system.

• Give knowledge transfer to your team in the concepts and practice used in GIT.
  • It is mandatory for developers to understand how Git stores change and how commits form a history of development and how all things work in GIT.
  • Identify training materials.
• Perform the actual migration to GIT.

Suggestions:

• Keep the following types of files: code files, versioned assets such as graphics and large configuration files.
• Remove the following types of files: database dumps, log files.
• Use a vulnerability checking tool.

Conclusion

By following the above key steps, you can have a systemic and risk-free migration. Planning, then acting, is critical in a successful code migration process.

— Amit Anan