Modernizing your ArcGIS Deployment

[MatthewMarino]

Every time a new version of ArcGIS is released I receive one particular question more often than any other.  The exact words can change but it's always something to the effect of "How am I going to move all of my users from ArcGIS Desktop to ArcGIS Pro"?   

A big part of my role at Esri is helping customers implement and configure the ArcGIS platform, and that extends to upgrading to the latest version of ArcGIS and installing the newest products. So when someone asks me this question they are usually expecting me to talk about a technology migration path for desktop users. But a straight path like that assumes users will perform a 1 for 1 swap of ArcMap for ArcGIS Pro over time, and that's often not the best way to address the underlying question. 

Instead of a need for migration I like to think of this as an opportunity for modernization. Migration generally focuses on the technology. Upgrades, patches, installing the latest product. Modernization may involve upgrading and new products but that's only a means to an end. It's really about moving to a new pattern. A paradigm shift. In our conversation about ArcMap and ArcGIS Pro that pattern is Web GIS. As we move from Desktop, to Server, to Web and eventually Distributed GIS new options present themselves that were previously unavailable. ArcGIS Pro and all of the other Web GIS native applications allow for new and powerful functionality that we can only leverage if we shift the way we look at using GIS. 

When working with users on modernization I almost always start by asking three simple questions: 

• Who are the users? 
• What location information do they value? 
• What answers are they after? 

Everyone that is using ArcGIS is trying to solve a problem, ask a question, or get an answer using spatial data. That problem, question, and answer come together as a workflow and the workflow, not the technology, is what we want to focus on.  Once we answer those questions we start reviewing the existing workflows and making a workflow by workflow recommendation on how to modernize each using one of three options. 

1. Desktop to Pro Workflow Transition: A one-to-one swap of technologies by rebuilding workflows in Pro using only out-of-the-box (OOB) functionality. If you can do it this is it's the preferred approach because it has the smallest learning curve, requires less change management and can likely be accomplished with minimal changes to data. Although you may be accessing data differently (i.e. through services instead of direct GDB editing) in many cases. This is your easy button but don't expect you can use it in every case.  
2. Desktop to a Web GIS Enabled Product Transition: When a one-to-one swap isn't an option (or an OOB app is a better fit than Pro) you can adjust the workflow you're using in Desktop to another Esri product.   Examples could range from something as simple as using collector for offline data collection rather than an ArcGIS Desktop with checked out data on a Toughbook, to more complicated changes that effect the underlying system architecture, like using a web app template and ArcGIS services to review and approve data changes rather than using a multitude of versioned databases and spending hours reconciling the edits. This option is often the most over looked. After years of comfortably working in ArcGIS Desktop our instinct is that we either need to move a workflow to Pro or build a plugin for Pro. But with the vast ecosystem of Esri Apps that leverage Web GIS we can often find a suitable (if not preferable) replacement for a desktop workflow using an OOB app that is fully supported and maintained by Esri. Sometimes changes like these require architectural or data adjustments, so while they may not be minor changes to a GIS administrator if done properly they can provide a very simple transition for the user.  
3. Desktop to Custom Technology Transition: In the past 10 years I've seen a great swing from customization being the default approach to any problem, to COTS over custom at all costs. But in the past few years we've seen the pendulum settle somewhere in between, and while configure first is still a great rule, customization is no longer frowned upon when needed. With the Developer tools available with ArcGIS this custom technology can take many forms. So think about your userbase when you are deciding how to go about building your new custom app, tool, or plugin. Think about what else the user of that workflow will be doing. Is this their only workflow? If so maybe a JavaScript app that's easy to maintain and can be built quickly is best. Do they have several workflows and most of them will be moving to a mobile app? Then maybe building with AppStudio makes sense so you limit that user's need to switch devices. Or are 99% of their workflows staying in the desktop with ArcGIS Pro? If so maybe a custom Pro plugin is worth the investment. It all depends on context.  

As you modernize your GIS and help your users make the paradigm shift to Web GIS keep these steps in mind so you can help them understand their options, and that a whole new ecosystem of tools and products are available to help them achieve their mission.