Considerations for Migrations

Server migrations, OS and product updates, and architecture and configuration changes are expected motions in maintaining a data science environment. This article aims to provide a framework for thinking through migration scenarios and offer best practices for developing a migration plan.

At a Glance

When approaching a migration, identify the relevant migration scenario(s) that define the scope of migration
For each migration scenario, understand the migration impacts to the hardware, Posit product, configuration, or components
Develop and execute a migration plan

Migration Scenarios

For the purposes of this article, a migration occurs when one or more of the following general scenarios is true:

Are you changing the server where the product(s) are installed?
Are you changing architecture or components?
Are you changing or upgrading your system OS?
Are you changing from a self-managed to a managed service?
Are you moving from open source or legacy Posit products?
Are you changing your authentication provider?

The scope of the migration is defined by which general scenarios above are relevant.

For example, a planned upgrade from RHEL7 to RHEL8 via standing up a new environment and also moving to a High Availability setup has a migration scoped to:

Changing the server where the product is installed
Changing architecture or components
Upgrading system OS

Migration Impacts

In general, the migration scenarios identified above will impact some combination of the Posit product, its configuration, or a component part (e.g., database, authentication)

When approaching a migration, use the information in the tabs below to understand the possible impact each relevant migration scenario will have on the Posit product, configuration, or component.

	Server Location	Architecture	System OS	Move to Managed Service	Move from open source or legacy products	Auth Provider
User/Content data directory¹	✅	✅	N/A	✅	✅	✅²
Metadata storage location³	✅	✅	N/A	N/A	N/A	N/A
Package caches⁴	✅	✅	✅	N/A	N/A	N/A
OS system libraries⁵	✅	✅	✅	✅	N/A	N/A
Logs and metrics	✅	✅	N/A	N/A	N/A	N/A
Mounted file systems	✅	✅	N/A	✅	N/A	N/A
Configuration files	✅	✅	✅	N/A	✅	✅

Develop a Migration Plan

Prior to commencing a migration, develop a migration plan, being cognizant of any internal organizational requirements for data retention and backups. Reference the respective Posit product administration guide for details on conducting migration tasks, and reach out to your Customer Success Representative to further discuss best practices in migration.⁶ Your Customer Success Representative can share additional resources, or coordinate with our Solutions Engineering team to address specific questions you may have.

As best practices:

We strongly recommend you back up your data and encryption keys before conducting any migration work.
When conducting a significant upgrade or change to the system OS, we recommend installing the new OS on a new server, installing the Posit product, and then migrating content to the updated environment. We do not recommend upgrading the system OS in place.
Utilize a staging server to minimize risk of production downtime.
In developing a migration plan, we strongly recommend not combining migration activities, rather, perform steps individually to minimize the size and scope of changes at each step.
If the scope of your migration includes a product upgrade, we recommend upgrading your Posit products first. Review the product Release Notes to understand the scope and impact of product upgrades.
Configuration changes, such as migrating to a Postgres database for content metadata, are less significant and can be conducted following more impactful migration activities, such as server migrations or system OS changes.

Footnotes

This is the content of the Posit product’s data directory. For Workbench, this encompasses user home directories. For Connect, this is the variable data, where deployed content and supporting package caches are stored. For Package Manager, this is the location where downloaded packages are written.↩︎
Impact to user data is scoped to mapping old unique user identification to new authentication method’s unique identifier.↩︎
Product metadata is stored in either a automatically-configured SQLite database (default) when the product is deployed on a single server, or with an external Postgres database.↩︎
Package caches on Workbench can include a system cache and user-level caches.↩︎
R and Python packages are built against the system OS.↩︎
If you do not know your Customer Success Representative, use the Contact Sales) form to be correctly routed↩︎