Migrating Artifactory offers flexibility, but the core principle remains constant: all your binary data (Filestore) and metadata (Database) must be successfully transferred to the new location.
The optimal method for your migration depends on several factors, including the size of your Artifactory instance, your acceptable downtime window, and the technical capabilities of your environment.
To help you determine the most suitable approach, consider these questions:
- What is the total size of your filestore?
- How much downtime can your organization tolerate for this migration (if any)?
- Are you migrating between different types of storage (e.g., local disk to S3)?
- Are you migrating between different database types?
What network bandwidth and file transfer tools are available between the source and target environments?
The following table gives the options available:
Method
|
Downtime/Continuous
|
Best For
|
Key Pros
|
Key Cons
|
| Basic import/export | Downtime | Small instances (< 100,000 artifacts) | Simplest process; Uses built-in Artifactory functions. | Requires downtime; Unsuitable for larger instances; Resource intensive |
| Downtime | Large instances needing a fast migration; Moving from one DB type to another | Straightforward; Less downtime than basic import/export; Works for larger instances. | Requires downtime (unless combined with other methods); Requires external tool/commands | |
| Downtime | Fast backup & DB consistency | Fast; Reliable backup solution | Must be same DB type; Requires downtime; Not available for Derby | |
| Continuous | Zero-downtime, high-volume setups | Multi-threaded; Controllable load; Continuous sync available | Overhead of CLI and plugin setup; Learning curve Not as fast as import methods | |
| Continuous | When the Transfer Tool is not suitable.Filling a data delta. | Continuous sync available | Slowest method as it is single-threaded per repository; Relies heavily on strong network; Not recommended for full migration | |
| Depends | Migrating installation method of Artifactory from one method (e.g. Debian) to another (RPM,K8s) | Fast and Straightforward Allows a transfer between different installation methods / application servers. | Requires an External DB. This no downtime method can not be used when switching between a VM installation and k8s, as we do not support a mixed k8s VM cluster. Switching between these methods will require a downtime |
Summary
This article provides a comprehensive overview of Artifactory migration, covering key concepts and comparing various methods with their respective advantages. We strongly recommend testing all steps in a staging environment before proceeding with a production migration.