Best practices and recommendations to keep in mind when migrating your JFrog Platform to the cloud
JFrog empowers DevOps organizations globally to curate, secure, store, and deliver the building blocks of all their mission-critical applications at scale. The JFrog Platform is a central part of your software delivery and keeping it running and up to date is critical.
When it comes to managing a self-hosted installation on-premises, it takes a lot of work. It requires regular maintenance, manual scale-up to meet demand, and upgrades to stay up to date. Migrating to a JFrog hosted SaaS infrastructure removes maintenance hassles, improving efficiency, reliability and security.
This guide was created to provide you with everything you need to know before, during and after migrating to the cloud. It includes resources and recommendations put together by the JFrog technical teams, based on customer experiences, to help you successfully complete your migration process.
Additional resources to help along the way:
JFrog Support
JFrog Documentation
My JFrog - Cloud Customer Portal
JFrog Academy
JFrog Cloud Status page
1. Planning the Cloud Migration Process
The first step in your cloud migration journey is defining your JFrog Platform cloud setup and topology, according to geographic location. If you haven't done this already, reach out to your JFrog account manager.
Before you start
Here’s what you’ll need:
JFrog cloud subscription
JFrog CLI installed
Note
Migration Limitations
Before starting your migration process, it’s recommended to go through the migration limitations. This will help improve your migration strategy. Learn More
External Authentication
When using external authentication providers, for example LDAP and Crowd, you’ll need to allow access to the cloud server using Cloud NATed IPs .
Docker Access Methods
When working in the cloud, by default Artifactory supports access to Docker registries using direct access. Update your Docker methods to use the cloud Docker URL.
For example:
<server name>.jfrog.io/<repository name>
Custom CNAME
* Applicable only to Enterprise X subscription level and above.
When working in the cloud, by default your server URL is <server name>.jfrog.io. Setting up a Custom CNAME will allow you to use a different or keep the same DNS name according to your needs. You can manage your custom domain names (CNAMEs) directly through the MyJFrog portal. See Managing Custom Domain Names for the official documentation & instructions.
Restricting Access to the Cloud Environment
* Applicable only to Enterprise X subscription level and above.
Restricting access to your cloud Platform will ensure that it can only be reached and used by your organization and not publicly available. This security setting can be done using whitelisting IP addresses. This process is self managed using My JFrog portal.
2. The Cloud Migration Process
The cloud migration process includes 5 steps:
- Enable configuration transfer on the target instance
- All services are temporarily shut down, except for JFrog Artifactory
- Set up the source instance for pushing files to the target instance
- Transfer configuration from the source instance to the target instance
- Disable configuration transfer on the target instance
- All services are back to normal
- Push the files from the source to the target instance
* Source: on-prem; Target: cloud
Follow the complete step-by-step guide to ensure a successful migration process.
The following are some key points to keep in mind while completing your cloud migration process.
Migrating the On-Prem Artifactory Configurations
An important part of migrating to the cloud is transferring your Artifactory configurations, such as repositories and user/group permissions.
While the cloud migration is enabled (with the enable configuration transfer setting in the MyJFrog Cloud Portal) all of the Platform services will be down, with the exception of the JFrog Artifactory service. This allows importing all Artifactory configurations and re-registering the other services (JFrog Xray, Insight, Pipelines, etc).
Once the configuration transfer is complete, make sure to disable the transfer setting. This will ensure that all your services are back up and Artifactory is scaled up back to its full capacity.
Controlling the File Transfer Load
The migration process adds an additional load to your existing Artifactory services. The thread pool is designed to limit the load on Artifactory during the migration, as the transfer can happen over a longer period in the background. Raising the plugin thread count can speed up the transfer time, at the cost of higher load.
To maintain consistency and decrease strain on your working system, you can control the workload setting according to your organization needs. For example, you can choose to increase the transfer load during off hours and decrease it during peak working hours.
By default, the file transfer uses a separate set of 8 threads to transfer the files from your on-prem server to the cloud.
For additional details and setting configurations, see this guide.
3. After Migrating to the Cloud - Testing
Once your cloud migration is complete, it’s recommended to start testing your new cloud Platform environment to uncover any potential issues before the go-live date. This includes performance and functionality testing.
During this time, make sure to update your cloud environment with any new changes being made to the existing On-Prem, such as creating new repositories or onboarding new users, is also done on the Cloud Artifactory during this period. Some of this can be automated. For example, you can set up Access Federation if your subscription allows it and you expect extended testing.
Identifying the Top Users
It’s important to identify your top users and have them test out the new cloud Platform early on in the process. Once you have a list of your top users, you should begin proactively contacting them in order to start your testing.
For example, you can use this demo script in order to identify your top users. This script works by analyzing the artifactory-request.log file, counting the user requests and sorting them based on repository, username, and IP addresses when needed.
Create a CI/CD Build Testing Plan
The users with the most logged activity should be responsible for the most important builds to test. We need their help to determine which of their builds need to be tested, and in what order. They should have a shared interest in ensuring a smooth migration to the Cloud. These builds are going to be the Key Performance Indicators and in a way will be the functional acceptance tests for the migration.
Consider delegating the testing process to these key development teams. This will allow them to sign off on the cloud migration before the go-live date.
Tip
Performance Testing - Check your cloud performance in comparison to your on-prem installation.
Migrating JFrog Xray Settings This can be done by exporting your Xray settings and reaching out to the JFrog Support team to import it to the new cloud Platform.
4. Going Live - Ready for Production
Updating your cloud data
Now that you’re ready to go live, we want to make sure that all of your repositories are updated with any newly deployed artifacts. To do this rerun the file-transfer step described earlier in the migration process.
JFrog Support Standby Window
Before you finally go live, notify the JFrog Support team, by opening a support ticket, about your upcoming cutover window. This will enable them to be available and ready to assist if any problems arise.
Start Using the Cloud Platform
There are two approaches to start using the new cloud Platform. One approach is to use a Custom CNAME and cut over traffic using a DNS Switch. The other approach is to systematically change your build configurations to use the cloud Platform URL.
Any On-Prem specific configurations in your CI/CD builds should be updated before going live to ensure nothing goes wrong. If a few failed builds are acceptable, and you know which ones to update, begin updating them systematically during the cutover phase.
Approach 1: CNAME Cutover
* Applicable only to Enterprise X subscription level and above.
Cutting over the traffic involves changing the DNS to point to the Cloud Artifactory CNAME. The CNAME should be ready to use from the previous stage of your migration process. Once your networking team updates the DNS, the cutover has occurred and all traffic will start flowing. Closely monitor the system of builds and the Platform cloud application.
Approach 2: Gradually Migrating
The second approach is to manually update all of your CI/CD builds and systems to use the new cloud Platform URL.
Each CI/CD environment and all Platform users should be updated to start using the new URL.
Check the on-prem artifactory-request.log file to make sure there are no incoming requests to it.