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:
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.
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:
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.
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:
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:
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:
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.
Cloud providers also bring new capabilities and functions that may not be available or feasible in an on-premises implementation. Examples include:
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.
Many organizations are pushed to move infrastructure to the cloud by a security mandate or an organizational policy.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.