This document is useful in when getting an existing Perforce Helix Core installation to the optimal operating environment from any starting condition. Whether the starting environment is large enterprise or small, on-prem or cloud, or on any operating system, this guide can help get to the optimal deployment environment.

This document focuses on software rather than hardware aspects of an optimal operating environment. While hardware is not discussed in detail, the migration and upgrade plans describe in this document provide opportunity to test and change out hardware.

This document does not discuss case sensitivity, case-conversions, or Unicode changes.

This guide assumes some familiarity with Perforce Helix Core and does not duplicate basic information in the Helix Core documentation.

Please Give Us Feedback

Perforce welcomes feedback from our users. Please send any suggestions for improving this document or the SDP to

1. Introduction

1.1. Optimal Helix Core Operating Environment

Getting to an optimal operating environment for Perforce Helix Core first requires defining various aspects of optimal. For our purposes in this document, optimal means:

  • SDP version 2020.1+. This is the SDP version from which SDP upgrades are fully automated.

  • Helix Core (P4D) version 2019.1+. The P4D 2013.3 and 2019.1 versions were major architectural overhauls requiring special upgrade procedures.

  • P4D Server is operating on Linux, on a a major version with plenty of support life left in it. As of this writing, that would be RHEL/Rocky Linux 9, or Ubuntu 22.04. RHEL/Rocky Linux 8 and Ubuntu 20.04 are actively supported as well, but with less runway available. For EOL dates of various Linux distros, see:

  • Physical layer (server machines, storage subsystems, etc.) is as desired.

The above constitutes the desired End State a migration.

In public cloud environments, an optimal Helix Core server be deployed instantly in an optimal environment by using the Enhanced Studio Pack (ESP), an offering on Amazon and Azure marketplaces.

1.1.1. Optimal Storage and NFS

This document doesn’t focus on hardware or storage components of the definition of "optimal" for Helix Core. Using NFS isn’t part of the "optimal" definition. At small scale, the cost and complexity introduced by NFS may not be worth the various benefits. However, as the scale of data increases to and above tens of Terabytes, options involving more scalable filesystem solutions like NFS start making sense and may even be required. NFS can be used in on-prem and public cloud environments.

ESP installations do not use NFS, and thus would require adjustment to handle very large Helix Core data sets.

1.2. Motivation

This style of upgrade is commonly referred to as a global topology upgrade, sometimes part of a larger infrastructure modernization effort. Such upgrades are commonly driven by desires to maintain performance, security, supportability, access to new product features, and in some cases to escape custom aspects of local infrastructure.

If all defined aspects of the desired End State are already met, you don’t need this document. Instead, use the standard upgrade procedure documented in the Upgrades section of the SDP Guide.

In some cases, there is an additional motivation: to get assistance for managing Helix Core servers, or perhaps to get out of that role entirely (perhaps due to departure of key personnel). If there interest in turning over the keys to your Perforce Helix servers, consider the Helix Remote Administration program.

2. Migration Style Upgrades

This document focuses on the Migration-Style Upgrade strategy, as opposed to in situ (in place) upgrades. In situ upgrades are preferred when your deployment environment is already optimal, as defined above in Section 1.1, “Optimal Helix Core Operating Environment”. If all of the aspects are currently in the desired state, you don’t need this document. Instead, use the standard upgrade procedure documented in the Upgrades section of the SDP Guide.

If the hardware, operating system, or P4D/SDP versions are not as desired, this guide is for you. A Migration-Style Upgrade is great when you need to make a big change in the least disruptive way possible. A key characteristic is that of a Migration-Style Upgrade is that your original server environment is largely left alone, with little or no change.

2.1. Big Blue Green Cutovers

In a Migration-Style Upgrade, a new set of server machines and supporting infrastructure (such as storage) is deployed that reflect the desired End State. This set of servers is referred to as the "Green" servers or infrastructure. The current, live production equipment is referred to as the "Blue" servers or infrastructure.

In preparation for an eventual cutover, Helix Core data is brought into the Green environment. This is usually non-disruptive to users operating on the Blue (live production) environment.

The Green Environment operates for a time as a test environment, allowing opportunity to test various aspects of the new infrastructure before it become the production infrastructure. Depending on risks and needs, testing can be cursory or extensive, lasting days or months.

If your current method of operating Helix Core does not produce a regular backup of checkpoints and versioned files, a change to the Blue environment will be required to get at least some basic form of checkpoint process in place. This may involve disruptive operations that might need to be scheduled in a maintenance window before the Green environment can be setup initially.

2.2. Start State

The starting environment can pretty much anything:

  • Any P4D version going back to 1995.

  • P4D Server operating on Windows, UNIX, Mac, or Linux.

  • Any legacy method of managing Helix Core:

    • An older version of SDP (prior to 2020.1)

    • Home-grown custom scripts

    • Management scripts provided by a 3rd party such as ICManage.

    • p4dctl

    • entirely with manual procedures (including possibly no manual procedures).

2.3. End State

At a minimum, the desired End State of a Migration-Style Upgrade is as defined above in Section 1.1, “Optimal Helix Core Operating Environment”. In addition to those aspects, you may choose to add other aspects to your desired End State, depending on the goals of your migration. In the mindset of "While we’re at it," some common examples things added to the End State definition are:

Even if you are "pretty close" to the definition of optimal, say on Rocky Linux 8 but otherwise modern, the Migration-Style Upgrade is the preferred method of getting to the modern topology. (If your environment is optimal in all other respects and only the P4D version is older, than you might consider an in situ upgrade). Other options are not discussed in this document, because the Migration-Style Upgrade has significant benefits that often make it preferable even when other options are possible.

The specific starting environment will impact migration options and procedures, as will be called out in this document.

Some big changes that call for a Migration-Style Upgrade include:

  • Windows to Linux migration.

  • Upgrade of a major operating system version (e.g. CentOS 7 → Rocky 8, RHEL 8 → RHEL 9, Ubuntu 20.04 → Ubuntu 22.04).

  • Upgrade of SDP from a version prior to 2020.1, where the SDP Legacy Upgrades applies, a well-documented but manual upgrade procedure. That document is for in situ upgrades of SDP — this document avoids the in situ procedure entirely by using a Migration-Style Upgrade.

The primary scenario this document is focused on is a migration to a cloud provider, though only minor adaptations are needed if going to an on-premises environment. We lean toward a cloud environments for documentation purposes, because we can assume more, and define more, with a cloud as a target. If your target environment is on-prem some aspects are available.

3. Migration Planning

  • To ESP, nor not to ESP?


3.1. Will ESP be used?

The Enhanced Studio Pack (ESP) should be considered if the target environment is Amazon or Azure. ESP is not available for on-prem, and not presently available for any other cloud environments. Even in cases where ESP is available, it may not be the best choice. Some cases where ESP is not optimal or would need adjustment afterward include:

  • You have a corporate policy that dictates machines must be launched from internally produced baseline virtual machines images. ESP is essentially a set of machine images, but of course not be based on any customer’s unique base images. (In some cases, an exception can be granted because ESP is reasonably well secured, using Security Enhanced Rocky Linux provided by Perforce OpenLogic).

  • You plan to use advanced storage solutions like NFS.

  • Your perforce operating system user is defined in LDAP rather than being local. (Note: We recommend using local accounts when you can for optimal reliability, but using an LDAP account is required when using NFS to ensure user IDs align across a fleet of server machines).


4. Migration Preparation

  • Build the Green Infrastructure.


5. Sample Test Plan


6. Sample Cutover Procedure

EDITME - Add content here.