In ArcGIS Enterprise the term migration describes an organization's requirements to move an existing deployment, or portions of it, to an alternate deployment. This alternate deployment may be newer, on a different operating system, or on a different infrastructure. Migration strategies can be used to move existing content from the original deployment to an alternate deployment.
Common strategies
Architectural and migration needs vary from one organization to another, as do the respective strategies and solutions. The specific strategy chosen to migrate content may vary depending on specific factors. Factors to consider when choosing a migration strategy include the following:
- What content needs to be migrated? This may include all content, all content and users and groups, or a specific subset of the content.
- What operating systems are involved? There are different considerations when moving from the same type of operating system, for example, Windows Server 2019 to Windows Server 2022, than when moving from a Windows deployment to a Linux deployment.
- What type of infrastructure is involved? The considerations of migrating content will vary when migrating content from ArcGIS Enterprise to ArcGIS Enterprise versus ArcGIS Enterprise to ArcGIS Online. There are also additional considerations when migrating from an on-premises deployment to the cloud and vice versa.
The sections below outline common migration strategies and include links to tools, help documentation, blogs, and other resources to support your work in these areas.
Migrate content from one ArcGIS organization to another
This strategy may be helpful if your organization intends to do the following:
- Promote content across individual organizations such as from development to staging to production.
Note:
An alternate approach to moving content through environments is to update the URLs of all of your organization's items and services. See Update the organization URL for more information.
- Maintain select content in ArcGIS Enterprise while migrating a selection to ArcGIS Online or vice versa (for example, to deliver a combination of private and public items).
- Maintain select content in one ArcGIS Enterprise deployment while migrating a selection to another ArcGIS Enterprise deployment (for example, within disconnected environments).
Migrate hosted content
When copying or migrating hosted layers, web maps, and items, you can use tools and resources in ArcGIS API for Python, the ArcGIS REST API, or the portal website. The following tools and resources will be easier to use if you have previous experience with the ArcGIS API for Python:
- The cloning content guide details how the clone_items() function is used across environments. The clone_items() function supports hosted services, web maps and apps, and other item types. This type of migration strategy should be considered when migrating all the content from one organization to another.
- As of 10.8.1, the arcgis.gis.GroupMigrationManager.create() function is available to export group content from an ArcGIS Enterprise organization as a package. Administrators can use this function to extract selected group content and import it into another organization's group. This function provides support for hosted feature layers, web maps and apps, and other text-based items. Item IDs are maintained during migration. This type of migration strategy should be considered when migrating a subset of the content from one organization to another.
- As of 10.8.1, the arcgis.gis.GroupMigrationManager.load() function is available to import an exported package to an ArcGIS Enterprise organization as group content. Once imported, item ownership defaults to the administrator who imported the package. Items can then be assigned to other owners as needed. This type of migration strategy should be considered when migrating a subset of the content from one organization to another.
If not familiar with the ArcGIS API for Python, the export and import group content operations can be used in the ArcGIS REST API to move content from one ArcGIS Enterprise organization to another. These operations are useful when moving content from a development to a staging environment or across disconnected environments. This type of migration strategy should be considered when migrating a subset of content from one organization to another.
Migrate referenced content
When migrating referenced content, GIS services that reference user-managed data stores will need to be published or shared to each of the ArcGIS Enterprise deployments. Sharing referenced services can be done using the following methods:
- Publishing your web layer from ArcGIS Pro. Services published from ArcGIS Pro will reference the data source used when sharing the web layer. This means new maps may need to be created if you want to reference different data sources.
- Publishing a service definition file (.sd) in ArcGIS Server Manager. All services published from this database connection will reference the same source data.
- Bulk publishing within the ArcGIS Enterprise portal. All services published from this database connection will reference the same source data.
Additionally, services can be automated using the ArcPy Sharing module, arcpy.sharing. This migration strategy should be considered when sharing the same GIS service to multiple ArcGIS Enterprise deployments at once.
Note:
While the scenarios above describe moving items across environments, sharing items across organizations is also common. In this case, items can be replicated across environments, for example, to deliver and distribute public and private items across organizations. For this strategy, you can use distributed collaboration. While distributed collaboration can be used for sharing content between environments, it is not designed for migrating content between environments.
Migrate an existing deployment from one machine to another
Your organization may need to move existing software components to newer hardware or a newer operation system. To migrate single- or multiple-machine deployments that are hosted on-premises or in the cloud from the same type of operating system to another, you can consider the following strategies:
- To replace a machine in your deployment without losing content or interrupting service, use the Join Site operation to migrate software components to another machine. The Join Site operation is available through the Portal Administrator Directory and the Server Administrator Directory.
- A slightly more involved workflow is to use the webgisdr utility. You may prefer this workflow, as it doesn't impact the work in your production environment. For more information, see Migrate ArcGIS Enterprise with WebGISDR.
Migrate an existing on-premises deployment to a cloud deployment
This strategy may be helpful if your organization intends to do the following:
- Add new capabilities.
- Improve system performance and capacity.
- Reduce system cost.
- Improve or comply with security standards.
To determine whether this migration strategy is appropriate for your organization, review the following:
- Enterprise and Cloud Migration page—Start here for an introduction to migrating to a cloud deployment.
- ArcGIS Enterprise and Cloud Migration guide—This guide provides a detailed approach to understand, plan, and act accordingly to address your organization's migration needs.
- ArcGIS Enterprise in the cloud blog—This blog provides an overview of cloud deployment.
- AWS CloudFormation and ArcGIS—Become familiar with cloud deployment tools available for AWS deployments.
- Deploy ArcGIS Enterprise on Microsoft Azure—Become familiar with cloud deployment tools available for Microsoft Azure deployments.
Upgrades and migration
Upgrading ArcGIS Enterprise software is not a migration strategy. When you upgrade ArcGIS Enterprise (including base deployment components, server roles, and so on), the goal is typically to gain access to new features, capabilities, and apps. For example, an organization may be using version 11.1 but is planning to upgrade to gain access to new features or apps available in 11.2. In this case, the existing deployment is backed up and the newer software version is installed on top of the existing software to bring it up to date.
However, the need to upgrade software is often done in conjunction with the implementation of a migration strategy—such as migrating to a new operating system or from an on-premises deployment to a cloud deployment.