Migration to Supplier Instance

• Pre-migration requirements
• Identify Repositories and Users
• Onboard to Supplier Instance
• Update your code
• Federate Repositories

Migrating a Supplier to the Supplier instance is a straight-forward process. Once you've identified the repositories and users who need to utilize the Supplier instance, a couple of ServiceNow tickets will get everything taken care of.

Pre-migration requirements

Before embarking on your JFrog migration, it's crucial to understand the fundamental distinctions between local and remote repositories, so you can identify how you are interacting the the platform and how you plan you storage in the new environment.

Local repositories are those hosted directly within your JFrog Artifactory instance, designed to store and manage artifacts that are produced internally by your organization. Remote repositories act as caching proxies for external artifact sources, such as Maven Central, npmjs.com, Docker Hub, or other public or private third-party registries.

Identify Repositories and Users

First thing, you must identify which users/groups are utilizing data in your project. You may already have an understanding of which suppliers you are working with. For ease of management, it is best to have the suppliers you are working with in their own security group(s).

Next, you will want to understand which repositories your suppliers are working in. Make a list of repositories that you collaborate with suppliers on.

Onboard to Supplier Instance

Once you have identified the user groups representing your suppliers, you can create a Service Now ticket (Submitting a ServiceNow ticket). You will need to request a new project on the Supplier instance. Additional instructions for this process is available here. The project on the Supplier instance does not have to be the same as what is on the Primary instance.

In addition to project creation, include which supplier groups need to be onboarded to the Supplier instance.

Once this is done, you can login to the Supplier instance (https://supplier.artifacts.ford.com), and begin setting up any repositories that you may need. This includes creating federation partners to any repository on the Primary instance that will need to be synced to the Supplier instance.

Update your code

Primary requirement for this migration will involve updating all configurations and references that point to your current JFrog URL from https://jfrog.ford.com to the new URL, https://fordsupplieractive.jfrog.io. This change is critical for all tools, scripts, and CI/CD pipelines that interact with JFrog Artifactory to ensure they connect to the correct instance post-migration. Furthermore, a crucial step in this process will be the regeneration and update of all personal access tokens (PATs). Existing tokens generated for https://jfrog.ford.com will not be valid for https://fordsupplieractive.jfrog.io, making it imperative to create new tokens and update them across all authentication points to ensure successful and uninterrupted access to your repositories and artifacts

If your use case primarily involves consuming artifacts solely from remote repositories, you will not be required to create a dedicated project. This is because, by default, remote repositories are configured to be visible and accessible to all users and groups within the JPD

Federate Repositories

Once you are satisfied with your project and repositories on the Supplier instance, you can request that your repositories are federated. Federation allows multiple repositories (even across instances of JFrog), can be kept in sync with the ability to read and write on all repositories within the federation group. We can also use federation as a migration tool, so even if you're only migrating the data, and you don't want them to be in sync in the future, include those repositories and stipulations in your submitted ticket. For more details, see the page Federate Repositories in the JFrog Platform.