The Timely Migration software requires the following prerequisites to be installed on the machine running the migration:
For TFVC destinations, Timely Migration installs and makes use of Microsoft's TFS APIs which are compatible with accessing 2008 through 2019 on-premise TFS / Azure DevOps Servers as well as Microsoft's hosted Azure DevOps offering.
For Git destinations, Timely Migration optionally makes use of the Git for Windows command line and Git LFS and relies on those prerequisites being preinstalled since they will be required on all client machines after the migration.
Additionally Timely Migration requires access to a SQL or SQL Express installation to create a staging database. The database engine may be hosted on a machine separate from the machine running the Timely Migration software. In order to be able to connect to the database, it must be configured to accept local and remote connections using both TCP/IP and named pipes.
Different Timely Migration source adapters will also have additional prerequisites:
History is important because it contains a record of what changes were made when, and that can be used to try to figure out why changes were made and what defects they were originally intended to fix. This allows future developers to consider why the code works the way it does to help keep them from reintroducing old defects and causing costly recycles.
However when migrating history, accidental changes and quirks with the way the original source control system was used will often show up during the migration phase as discrepancies that will need to be reconciled. If the original source control database wasn't regularly maintained, database corruption could also require reconciliation.
Because of the need for reconciliation, it should be expected that you will need to plan for time to watch the migration to make sure it finishes and to examine what was migrated. You will need to determine whether problems resulted from the migration process or if the problem lies with the origin source database, and if those problems are important and need to be resolved or can be skipped.
For example certain version control systems may treat files with the same name but difference cases as separate files. With TFVC these files are treated as the same file. When migrating changes you may have files ‘a’ and ‘A’ get renamed to ‘B’ and ‘C’. Since in TFVC there is only one file A it cannot be renamed twice and a migration error will result and need to be reconciled.
When determining if anything needs to be reconciled, it is recommended that you use a non production server as your migration target. This prevents the production server from being filled with files that will never be used but still take up database space and be subject to periodic maintenance. Once reconciliation has been performed and you are happy with the results you can rerun the migration with the production server as the migration target.