Upgrade and/or Migrate Posit Team — Overview

Overview

Recommended procedures for upgrade and/or migration of Posit products. 

flowchart LR
    A((0))
    B((1))
    C(("✔"))
    D((2))
    E(("#9829;"))
    A---B
    B---C
    C---D
    D---E
    A ~~~|"<b>Overview</b>"|A
    B ~~~|"<a style="text-decoration:none" href="phase1-upgrade.html">Phase 1\n Install\n Upgraded\n Products</a>"|B
    C ~~~|"<a style="text-decoration:none" href="phase1-test.html">Test\n Phase 1</a>"|C
    D ~~~|"<a style="text-decoration:none" href="phase2-migrate.html">Phase 2\n Migrate\n Data</a>"|D
    E ~~~|"<a style="text-decoration:none" href="rollout.html">Rollout</a>"|E
    
    %% click A href "../"
    click B href "phase1-upgrade.html"
    click C href "phase1-test.html"
    click D href "phase2-migrate.html"
    click E href "rollout.html"

    classDef activePage fill:#447099, stroke:#D1DBE5, color:#fff, padding:4px
    classDef inactivePage fill:#D1DBE5, stroke:#447099, color:#151515, padding:4px
    classDef activeDesc font-size:20px
    class B,C,D,E inactivePage
    class A activePage

Purpose

These procedures describe how to conduct a migration or upgrade of the Posit products (Posit Package Manager, Posit Workbench, and Posit Connect). Upgrade of the Linux operating system (OS) is also considered.

Scope

If you are currently running a supported product version and only need to upgrade that product, refer to the product upgrade instructions:

If you are upgrading from an unsupported product version, changing servers, and/or changing the Linux OS, follow these procedures.

Applicability

  • These procedures directly address single-server installations for each product. Use these procedures as a basis for developing an upgrade plan for high availability deployments, or configurations that deploy in / integrate with external clusters.
  • Out of scope:
    • Architecture changes are out of scope of these procedures. Consider architecture changes as separate efforts following successful OS and product upgrade.
    • Upgrades to supporting infrastructure, such as the PostgreSQL product database, are out of scope.
    • Database administration and Linux administration tasks are out of scope for Posit support.

Requirements

Phase overview

These procedures stand up a net-new Posit Team environment (Package Manager, Workbench, and Connect) in isolation from the existing production deployment. This method brings all three products up to date in a two-phased approach. Upgrading the OS affects Python and R packages in the production environment. Perform work on dedicated staging servers so that the production environment remains isolated while confirming package compatibility under the new OS.

Package Manager is installed first to configure it as the default repository source for both Workbench and Connect. If you don’t have a professional version of Package Manager, we recommend configuring Workbench and/or Connect to use Posit Public Package Manager. In either case, Package Manager provides precompiled Linux binaries for packages, which accelerates package library rebuilds and avoids many package installation issues due to missing system dependencies.

This two-phased approach is:

Phase 1. Stand up and configure a new Posit Team environment in a separate staging environment:

  • This is fully isolated from the existing production deployment. This staging environment has no content but is configured per the production requirements (e.g., authentication, network connections, drivers, versions of Python, R, and Quarto). During Phase 1 activities, the production deployment can remain online. Conduct testing and verification of the environment before moving to Phase 2 to keep changes to a more narrowly scoped statement of work. Phase 2: Migrate user/content data and product database:

  • The second phase covers the movement of content and data, rebuilding environments as required. To preserve consistent state between the content data and product database, the production environment must be shut down when snapshots are taken for migration purposes. You can turn the production environment back on following snapshots, but be aware that any changes made after this point aren’t captured in the new environment. Enact a separate plan to capture any new work or deployments in production occurring during this time. Upon completion of the two phases, release the entire environment to production as one unit.

An in-place upgrade of the Linux OS isn’t recommended.

Consider an in-place OS and product upgrade if you:

  • Are upgrading from a supported Posit product version to another supported product version. Refer to the list of Supported Pro product versions to determine applicability.
  • Have a staging server available to perform all work in an isolated environment. Without a staging environment, troubleshooting issues is challenging because the old environment isn’t available for reference.
  • If your OS vender provides satisfactory support (if any) during the in-place OS upgrade.
  • Recognize that upgrading the OS also updates system libraries. The updated system libraries are often incompatible with older R and Python package versions, package binaries installed under the old OS, or other software packages installed on the server. At the time of the upgrade, incompatibilies don’t always surface, making them difficult to troubleshoot.

Upgrading the OS in place requires that you reinstall the Posit software, and all versions of R, Python, and Quarto. They’re not upgraded as part of the OS upgrade.

If you satisfy the requirements listed above and choose to forgo the recommended phased approach outlined, review the overview of How to Upgrade the Linux OS and Posit Product(s) In-Place.


Next Step:
Proceed to Phase 1

Back to top