Enterprise and cloud migration

The organizations that are most successful in their use of GIS continuously modernize to take advantage of new capabilities, maximize technology investments, and achieve their business objectives. Modernization is a process with many definitions, but often it involves moving – or migrating – users, groups, or content from one GIS system to another. Today, many modernization projects involve migrations to cloud infrastructure.

ArcGIS Enterprise and cloud migrations can vary in size and scope depending on the individual environments in question and the many ways that the software is deployed and managed by different organizations. Regardless of the simplicity or complexity of the migration, all migrations require an understanding of the business and user context and a plan of action with an established measure of success.

A few of the most common migration patterns include:

  • Moving from old to new infrastructure
  • Moving from an on-premises environment to a public cloud environment
  • Moving from one cloud provider to another
  • Moving from ArcGIS Online to ArcGIS Enterprise

This topic discusses the why and how of migration. With these ideas, you can better evaluate if a migration is the right choice for your organization. Additionally, you can understand what actions you can take based on the pattern of migration you choose. This overview addresses a migration in the same way that you would develop and implement a geospatial strategy: understand, plan, and act. Rather than following a specific migration scenario, this topic aims to provide information and guidance that is relevant to all scenarios.

Understand reasons for migration

First, consideration must be given as to the why of undertaking a migration and to what environment or configuration you are migrating to. To establish the why, the first step is identifying the business goals of the migration. You want to establish business goals that are specific, so that you will be able to measure your efforts and see if you have met the goals later. If the goals are not specific, it becomes challenging to know if you have succeeded. In an example of moving from an on-premises ArcGIS Enterprise deployment to a commercial cloud provider, possible goals could include:

  • Improve system performance
  • Reduce system cost
  • Add new capabilities
  • Improve or comply with security standards

These are good starting points and are generally achievable with a migration to the cloud, but they are too general to help define specific actions and approaches. In the next section, some common reasons are provided for an organization to pursue a migration and looks at ways to make these goals more specific and useful.

Improve system performance

Organizations often see performance improvements when they move their infrastructure to a commercial cloud provider due to the performance optimizations and options with most IaaS providers. Some of the ways that cloud infrastructure can improve performance are:

  • Optimized infrastructure: Removing IT constraints and compromises from the selection of system components
  • Scalability: Support for vertical scaling of systems and hardware resources to increase capacity without re-architecting
  • Elasticity: Support for horizontal scaling of systems and hardware resources to increase capacity
  • Reliability: Increasing an organization’s trust that a system is performing well and providing consistent responses
  • Redundancy: Including extra components in a system so it will continue to function in case of a component or infrastructure failure

These five points illustrate some of the functional ways that a cloud deployment can improve performance but are still missing the specific information about how any one of these goals will help an organization directly.


For best results, define system performance goals using success criteria.

Consider an organization’s goal to increase system performance from one that is general to one that is defined with success criteria:

  • General: Increase performance
  • Targeted: Increase performance by doing X to improve the workflow for Y
  • Defined with success criteria: Increase system performance by reducing map service draw times for the main parcel viewer application during daytime hours.

Reduce overall system cost

Cost savings or the potential for cost savings is one of the most common reasons that organizations look to move to a cloud provider. Some cost benefits of migrating to the cloud are:

  • Avoiding hardware refresh: Machines can be imaged and redeployed on new VMs without startup costs
  • Paying as you go: No up-front cost for physical machines
  • Using non-persistent environments: Reduced need for development/staging/test environments as they can be spun up on demand
  • Building to cost: Wider range of options to balance performance and cost
  • Budgetary tracking: Costs are clearly stated for individual instances and environments

A good goal focused on cost might be to reduce overall system cost by changing to a load-based scaling model that deploys additional ArcGIS Server machines under load but spins them down during quiet periods.

Add new capabilities

Cloud providers also bring new capabilities and functions that may not be available or feasible in an on-premises implementation. Examples include:

  • Load balancing: Cloud load balancing is the process of distributing workload and computing resources in a cloud computing environment. Load balancing allows enterprises to manage application or workload demands by allocating resources among multiple computers, networks, or servers. Most cloud providers include robust load balancing tools in their offering.
  • Serverless computing: Small, short-lived computing environments can be used to run frequent processes, automate workflows, and process data for future outputs.
  • Elastic storage: Storage allocations and containers in a cloud environment are generally flexible and often easy to expand or duplicate for other use cases. Cloud providers also offer managed relational database systems that can provide enterprise geodatabase functionality with less management overhead.
  • Automatic updates: Cloud-native computing environments often update automatically to take advantage of operating system patches or security configurations.

A goal related to new capabilities might be to improve our GIS data editing workflows by moving our geodatabase to a managed database provider, publishing image services, and directing our editors to use web applications.

Improve or comply with security standards

Many organizations are pushed to move infrastructure to the cloud by a security mandate or an organizational policy.

  • Meeting an organizational mandate: “Cloud first” policies are common at the state, local, and federal government levels, which guide new deployments towards cloud environments. Many commercial companies are also following this approach.
  • Using a shared security model: Using an IaaS or PaaS provider reduces the responsibility for a cloud customer, as the provider manages the cloud infrastructure and backend, while the customer is primarily responsible for what is in the cloud. This shared security model allows customers to narrow their focus to application and usage security.
  • Maintaining physical security: Commercial data centers, physical access restrictions, power, climate, and temperature management.

A specific goal related to security standards might be to implement ArcGIS Enterprise in a zero-trust network environment, including managing inbound access through a WAF appliance provided as a PaaS component.

Some of the goals you set for security may be more clearly reached than your other goals. For example, meeting a mandated government security standard like FedRAMP or commercial standards like SOC-2 is a pass or fail initiative.

Once you’ve established clear and specific goals and a way to measure success, it is time to begin planning the migration.


Once you have a firm understanding of your goals, success criteria and challenges, the next step is to create a plan of action. The following eight high-level steps are provided below as a starting point.

Complete an initial inventory

Before you move forward with a migration, you need to broadly understand what content, systems, and functions are going to be migrated. Think beyond a list of features and services. Examine the processes and workflows your organization uses. What information is critical to your mission and what capabilities, or skills are needed to maintain it?

Review existing architecture

Although the state of the existing system may not be anything like the design for the target system, it is important to understand how and why the existing system is built the way it is. Understanding the deployed technology and its configuration will expand your knowledge of how your users interact with your system and how they will expect to interact with it once the migration is complete.

Establish targets & milestones

Even if the migration is not imminent, establish a clear timeline and adhere to it. Use your success criteria to create milestones to measure whether you are meeting your schedule and if each phase of the migration is successful. Plan enough time for testing the workflows, validating acceptance of the target system, and providing knowledge transfer to staff so they know how to shift their workflows to the new patterns.

Define roles & responsibilities

Clearly define who is responsible for the different steps and parts of the migration. Think about everything that needs to happen to get this accomplished - this is not just the implementation of the technology and movement of content but an understanding of how it affects everyone in your organization. The required roles will include everything from running the initial meetings to gathering stakeholder feedback, completing training on the new systems and guiding change management procedures that will happen after the system is designed, implemented, and tested.

Complete a detailed inventory

With the previous steps completed, it is time to complete an inventory reaches a level of detail that you would feel comfortable providing for an audit. No user should feel left behind because a small detail that is critical to them was overlooked. Identifying the types of content included in the system, the configurations, and URLs in use by your users, and the software components that are installed will all help you design the migration approach with more confidence in its success.

Design the target architecture

With a deeper understanding of every piece of data, user, workflow, and process that needs to be migrated you should have many of the components that you need to design the new system. Allow for the time and effort for an architect to gather requirements from anyone they might need to work with and allow them to thoroughly document the new target system. Be aware of any major differences in your target environment, such as a domain change, authentication change, new security rules, and so on.

Determine an appropriate migration method

There are a variety of different technical methods that can be employed during an enterprise migration. Some methods use ArcGIS Enterprise out-of-the-box functionality like the WebGIS DR tool or the Join Site approach. Other migrations may require more hands-on methods such as Python scripting to move content. The specific conditions of your migration, and the differences between the source and target environments will dictate which methods you need.

Document the migration plan

Finally, make sure to document every part of the migration plan so you can refer to it later. This document is your roadmap during the migration and should explain the prioritized activities you’ll undertake to successfully complete it. As you go through the migration itself, the plan can be used to track progress against your schedule, report on progress to stakeholders, and verify that all steps have been fully completed.


With your plan in hand, it is time to act. All the steps you have taken up to this point should provide a clear picture of what activities need to take place, the order of operations, and the measures that will be used to evaluate if the migration is a success. Use the steps below as a guide to some of the key steps.

Prepare and clean up the source system

Begin with the existing system. Make sure that any changes to the data, infrastructure, applications, or anything else required on the source system is ready. This includes creating copies and backups of your data and VMs. You may also want to set the source system to a read-only configuration so that users cannot create new content while the migration is taking place.

Ideally, take the time to clean up content from this system. If you can remove unneeded or unused content from the source system, the migration itself will be smaller and the impact to the users will be shorter in terms of time without full access.

Prepare the target system

Use the system design that was built during the planning phase to deploy your target architecture. Once the target system is deployed make sure to run your normal environment validation steps to ensure the system is performing as expected. Checks like connecting to ArcGIS Enterprise from a browser or desktop, creating a web map or application, registering an enterprise geodatabase, and publishing a service are helpful in establishing that the baseline functionality is working properly. Moving a small amount of representative test data from the source system will help you perform these steps. Note that for some methods like WebGIS DR migrations, the target system may be configured in a way that it is only fully accessible or functional from the target machines, not to all users.

Conduct migration

Begin moving users, groups, and content from the source to the target system using the methods your chose during the planning phase. Ensure that you make frequent checks during this process and record any instances of migration failures or content issues. These notes will be critical if you need to roll back any part of the migration.

Verify migration

Work with a few existing users that were migrated to the new system during the last step to have them verify that their workflows and processes work as expected using the new system, and that all their content appears and is correct. Make this an iterative process – once a group with similar workflows and needs has validated that they can work as expected, bring on a new group. Try to reduce variables as much as possible, so if you do run into a problem, it will be easier to identify the origin.

Conduct post-migration modernization

Sometimes it makes more sense to migrate as-is from the old system to the new one without making any modernizations. An example of this is if you wanted to make sure that your users’ workflows would still work in a new cloud environment before upgrading the deployed version of ArcGIS Enterprise. If that is the case now that the users, content, and workflows have been verified, you can begin upgrading or adding any technology that you were unable to handle during the initial implementation. Take the time to re-verify workflows with your users afterwards.


Another common migration method uses the migration window as a chance to upgrade the system - after the migration is completed (at the same release of the software), an upgrade can be completed during the period of user downtime, combining the upgrade and migration into one process.


Not only should every step of the process so far be documented for reference, but you also need to document any new operational and maintenance steps that you will be taking and how they will be carried out. Tasks like monitoring, upgrades, patching, testing, tuning, and the governance plan you intend to follow to make sure the system continues to operate as desired.


With everything now in place, conduct any additional knowledge transfer, training, or change management activities that you still have planned. These can be for users, consumers, administrators, or stakeholders.


At this point, you should have a new, operational system that meets your organization’s growing needs. As stated previously, migrations often go hand-in-hand with modernization. Don’t look at this process as finished but as the start of a continuous process of modernizing your GIS. Look at what the future holds now that you’ve finished the migration and consider what enhancements could be done over time to keep your system up to date.