how to migrate_

Ok. So you want to migrate your software project to a new development team, whether it’s an internal team, a freelancer, a contractor, or an agency. Here’s how.

Handing over a software project to a new development is an important process. The handover could be A transfer from:

    • An external development team to an internal team,
    • An old development team to a new one, OR
    • An old developer to a new developer.

Regardless, in each scenario, the process is the same. And that process is: to gather the information required in order to take over.

Here are the six handover processes:

  1. Version control
  2. Dev ops
  3. Ticket or bug tracking
  4. Documentation
  5. Tests
  6. Code refactor

laptop with pen

version control

All software development projects should use ‘version control.’

Version control is where the repository is transferred over to the other party when a project is handed over.

  • Bitbucket has some information on how to do this here.
  • And GitHub has their own section here, too.

Repositories keep a history of all development changes and bug fixes. They shouldn’t be lost during the transfer of the project code.

code on laptop

dev ops_

Most software projects are developed with dev ops, which can include a wide range of tools, including Docker, Ansible, Kubenetes, Jenkins, and Travis to name a few.

When handing over your project, it’s important to understand how these tools are used on the project. Documenting these processes will help when transferring over any project.

computer screens

ticket or bug tracking_

Legacy software will tend to include a feature or a bug list. It’s important to view, and to have knowledge on what this is.

After understanding this, the development team can take a look at the code base, and they can see where to make fixes, by asking current developers.

glasses with computer

documentation_

Documentation on any development or update procedures will help tremendously.

If documentation is not available, the new developers should be in a good position to write this. They will know very little about the system, so getting help from the existing team, and documenting this process will help a lot.

Documentation can (and should) take many forms:

  • Formal documents,
  • Comments in the code, to clarify the intent of the tricky bits,
  • Class and interaction diagrams at different levels of abstraction.

macbook

tests_

Access to testing scripts will help when adding new features. If tests are not available, it’s important to find out:

  1. What the main functions of the application(s) are,
  2. Any parts that are susceptible to bugs.

If you can write tests before a handover, that would be a great investment, and it’ll save a lot of time in the future.

mac code

code refactor_

Code can always be improved for a variety of reasons, updates, and speed, etc.

With large applications, refactoring the code needs to be strategic, i.e. what will bring the most benefits. Therefore, understanding what parts of the code may need this in future will also be very useful.