Description
Migration to cloud/ JFrog Saas using our JFrog CLI tool is a 2-step process:
1. Migration of configuration
2. Migration of data
The first step, configuration migration, can be achieved in 2 ways:
- Using transfer-config - this option is used to overwrite any existing configuration on Saas
- Using transfer-config-merge - this option is used to merge several configurations from different sources/targets
The transfer-config-merge option can lead to conflicts as the repository configurations might differ between the source and target instances. These conflicts would be generated in the ‘transfer-config-conflicts.csv’ file.
The CSV file generated lists the discrepancies with these parameters:
- Type: Type of conflict (usually repository)
- SourceName: Source repositories Name
- TargetName: Target repositories Name
- DifferentProperties: The property that is causing the conflict, for example: package type, virtualRetrievalCachePeriodSecs, resolvedockertagsbytimestamp, xrayIndex,artifactoryRequestsCanRetrieveRemoteArtifacts, bypassHeadrequest, etc
Screenshot of the transfer-config-merge option used with several discrepancies found:
Below are some of these discrepancies explained:
PackageType: Occurs when a repo of the same name is already present in the SaaS instance, but of a different package type.
On-prem:
SaaS:
xrayIndex: Occurs when JFrog Xray is not integrated in On-prem, while it is enabled in the Cloud or vice versa
On-prem:
SaaS:
virtualRetrievalCachePeriodSecs: Occurs due to the difference in the Metadata Retrieval Cache Period (which by default is usually 7200)
On-prem:
SaaS:
Repositories: Occurs due to any difference in the repository configuration, like default deployment, aggregation within the virtual repository, etc.
For example, here it is due to difference in the default deployment defined.
On-prem:
SaaS:
Resolvedockertagsbytimestamp: Occurs when there’s a difference in a parameter present in the advanced section of Docker repository configuration
artifactoryRequestsCanRetrieveRemoteArtifacts: Occurs when there’s a difference in a parameter present in the Virtual repositories configuration:
Resolution
The conflicts can be simply resolved by correcting the relevant properties in the source or target server, or for discrepancies like ‘package type’ - delete the repository currently present in the SaaS and reattempt the configuration merge.
Once the correction is done, it is recommended to run the transfer-config-merge again to verify if the conflicts are resolved, i.e. they will be removed from the csv file.
Optionally, the transfer of the conflicting projects or repositories can also be excluded by making use of ‘--exclude-repos’ or ‘--exclude-projects’.