The Unsupported Estate: What Remains After ArcMap Retirement

ArcGIS Desktop, including ArcMap, retired on March 1, 2026, and Esri, has no plans for future ArcMap releases. For teams still using it, however, the work may look much as it did before: asset information gets updated, maps get produced, and other departments receive the outputs they expect. Early movers can leverage Esri’s migration offers that come with no upfront cost keeping both licenses supported until the final maintenance term. 

In the migration discussions I have been part of, the harder question has been why a particular workflow remains. A connected system may depend on its output, or experienced utilities personnel may perform steps that never made it into the documentation. Those details determine how much work a transition actually involves. 

Perpetual-license holders can continue using the included applications while they transition; subscription access ends when the subscription expires. Updates, patches, and hot fixes had already ceased under Mature Support in March 2024. Retirement did not switch off every installation. 

I would want to understand how the remaining workflows are being kept operational and what that requires of the team. Following one business-critical output from start to finish can tell you more than a desktop inventory. 

Across engagements, I have seen organizations become stuck in the architecture surrounding ArcMap. The team may know how to move its desktop work but cannot do so independently because another enterprise system depends on the existing workflow. 

Consider an illustrative workflow, rather than a specific customer case. A GIS team maintains asset information in ArcMap and supplies an output to a maintenance system. A connector handles the transfer, a custom plug-in prepares part of the output, and experienced utilities personnel applies a correction that was never written into the procedure. The workflow runs reliably enough that nobody needs to examine the whole sequence. 

Now suppose a planned database or operating system update prompts compatibility testing. ArcMap still opens, but the team must establish whether the connector and plug-in will continue to work. The original developer is unavailable, and nobody has confirmed whether the source code and build instructions are sufficient to rebuild the plug-in. Modernization and migration efforts might be potentially risky as the long-term maintainability of the plugin remains unverified. 

If the transfer fails, the maintenance team may no longer receive updated asset information through its normal process. Moving the desktop application alone would leave that dependency unresolved. The GIS team first needs to understand what the maintenance system expects, what the custom component does, and why the analyst makes that correction. It can then decide which functions to retain, redesign, or replace. 

The underlying problems are ones I have encountered in delivery: connected systems that cannot move independently, and operational nuances are apparently not included in the client’s workflow documentation. During migration, an apparent gap in the new environment can turn out to be a step in the old process that nobody captured. 

What concerns me is the effort this demands from the people running the environment. Teams spend time configuring, reconfiguring, and working around limitations simply to keep normal work moving. The conversation about efficiency comes later; first, there is an exhausted team with less time for its intended work. That burden deserves attention even when the business continues to receive its outputs. 

“It still works” is useful information, but I would want more before recommending continued reliance on a workflow. Someone needs to explain the basis for that decision. 

For a security review, audit, or records discussion, I would explain what the process does, which systems and information it touches, who owns it, and how the organization would respond if it became unavailable. 

Continued ArcMap use does not, by itself, establish noncompliance. The responsible teams need to assess applicable obligations, internal policies, controls, and the specific use of the workflow. 

Where a workflow produces records the organization must retain or reproduce, establish how the output was created and what a replacement must preserve. Could someone repeat the process if the usual utilities personnel  was unavailable? 

Temporary retention can be a considered decision. Document the reason, accountable owner, controls, recovery arrangements, and conditions that would trigger another review. Past reliability alone is an insufficient basis for deciding how long to continue. 

I would use the time while a workflow is functioning to involve the people needed for the transition, including those outside GIS. Their availability and priorities matter before a migration date is agreed. 

You may need the GIS Specialist who understands an undocumented step, the database team planning an upgrade, the business owner who validates the output, and a partner specialist. Budget approval does not automatically put them on the same calendar. 

Ask what each person needs before work begins. A specialist cannot assess a custom component effectively if nobody has located its intended workflow code or established what it does. 

Before validating a replacement output, agree on what the business requires. Before finalizing a migration cutover plan, test which components must change together. 

Work backward from a relevant event: a connected-system upgrade, a planned staff departure, or an operational window for changes. Allow time for discovery, testing, user validation, and recovery planning. Waiting for a failure can leave the same people investigating the workflow while trying to restore service.

When funding is limited, I would give compliance obligations and operational consequences more weight than familiarity. A workflow supporting a compliance process does not necessarily need immediate migration, but its requirements and risks deserve early assessment. 

Start with workflows whose failure could interrupt a critical service, prevent a required output, or leave no practical fallback. Confirm the consequences with the business owner and the relevant security, compliance, or records teams. 

Then identify what could force a change. A scheduled database upgrade may make one workflow urgent. An undocumented custom component may make another require early investigation, even if its implementation comes later. 

I would assess the most consequential workflows early, even when they are unlikely to migrate first. Finding their constraints gives you time to address dependencies while completing other work. 

Choose the treatment deliberately. Some workflows can migrate with limited redesign. Others need a different integration approach, a replacement process, or retirement because nobody needs the output anymore. Temporary retention may be appropriate where current needs are met, and the risks can be managed. 

Use the budget to address the greatest business consequences while preparing the complex changes. Include the work your team postpones maintaining the current environment when assessing the cost of continued operation. 

These four questions can help the GIS team, system owners, and business users agree on the next step. 

Map out every consumer, receiving system, custom python script, manual workaround while keeping it alive while ensuring critical workflows continue uninterrupted throughout the transition. Follow the business output beyond the desktop. Identify its users, receiving systems, custom components, manual steps, and the people whose knowledge keeps it working. 

Consider technical and organizational changes, including upgrades and staff departures. Distinguish dependencies you have tested from those you assume will continue to work. Patch of an operating system, a server upgrade, or a key departure could break this workflow tomorrow. Hence, it is advisable to distinguish validated outcomes from assumptions. 

Identify the business activity affected and how long the interruption can be tolerated. Confirm who can perform any fallback, whether it has been tested, and its practical limits. 

Agree who will authorize the next step, what information they need, and when they will decide. If the workflow remains temporarily, set a review point. 

I understand why teams continue to use ArcMap. It has a substantial range of capabilities, and some existing workflows still deliver what the organization needs. 

My concern is how much effort that continuity requires. When experienced people spend more of their time reconfiguring the environment and working around its limitations, there is less capacity left to prepare what comes next. That is a reason to begin the assessment while the workflow is still functioning. 

Start with one workflow your business depends on. Ask the people who run it to walk you through the entire process, including the steps they have never needed to write down. That conversation will help establish what a transition needs to preserve.