在使用 GIS 方面最成功的组织会不断进行现代化改造，以利用新功能，尽可能提高技术投资并实现其业务目标。 现代化是一个具有许多定义的过程，但通常涉及在两个 GIS 系统之间移动或迁移用户、群组或内容。 如今，许多现代化工程都涉及向云基础设施迁移。
ArcGIS Enterprise 和云迁移的大小和范围可能会有所不同，具体取决于考虑的各个环境以及不同组织部署和管理软件的多种方式。 无论迁移的简单性或复杂性如何，所有迁移都需要了解业务和用户环境，并根据既定成功衡量标准制定行动计划。
一些最常见的迁移模式包括：
本主题讨论迁移的原因和方式。 根据上述理念，您可以更好地评估迁移是否是组织的正确选择。 此外，您还可以根据所选的迁移模式了解可以采取的操作。 本概述以与制定和实施地理空间策略相同的方式处理迁移：了解、规划和行动。 本主题旨在提供与所有方案相关的信息和指导，而不是遵循具体的迁移方案。
首先，必须考虑进行迁移的原因以及要迁移到的环境或配置。 要确定原因，第一步是确定迁移的业务目标。 您希望建立具体的业务目标，以衡量您的努力并在之后查看您是否达到目标。 如果目标不具体，要了解您是否成功就变得具有挑战性。 在从本地 ArcGIS Enterprise 部署迁移到商业云提供商的示例中，可行目标可能包括：
建议从上述目标开始，通常可以通过迁移到云来实现这些目标，但它们过于笼统，无法帮助定义具体的操作和方法。 下一节介绍了组织进行迁移的一些常见原因，并说明了使这些目标更加具体和有用的方法。
由于大多数 IaaS 提供商都提供了性能优化和选项，因此组织在将基础设施迁移到商业云提供商时通常会看到性能改进。 下面是可用于提高云基础架构性能的一些方法：
上述 5 点说明了云部署可以提高性能的一些功能方式，但仍然缺少有关上述任一目标如何直接帮助组织的具体信息。
为获得最佳结果，使用成功标准定义系统性能目标。
假设组织的目标是将系统性能从一般性能提高到使用成功标准定义的系统性能：
节约成本或可能节约成本是组织希望迁移到云提供商的最常见原因之一。 迁移到云的一些成本优势包括：
关注成本的良好目标可能是通过切换为基于负载的缩放模型来降低总体系统成本，该模型根据负载部署其他 ArcGIS Server 计算机，但在静默期间关闭这些计算机。
云提供商还带来了在本地实施中可能不可用或不可行的新能力和功能。 示例包括：
与新功能相关的目标可能是通过将地理数据库移动到托管数据库提供商、发布影像服务并指导编辑者使用 Web 应用程序来改进 GIS 数据编辑工作流。
许多组织受到安全要求或组织策略的推动，将基础设施迁移到云端。
与安全标准相关的特定目标可能是在零信任网络环境中实施 ArcGIS Enterprise，包括通过作为 PaaS 组件提供的 WAF 设备管理入站访问。
与其他目标相比，您为安全设置的某些目标可能更容易实现。 例如，满足强制性政府安全标准（如 FedRAMP）或商业标准（如 SOC-2 ）是一项要么通过要么不通过的计划。
在您建立明确而具体的目标和衡量成功的方法后，即可开始规划迁移。
在您对目标、成功标准和挑战有了深入的了解后，下一步就是制定行动计划。 下面提供了以下 8 个高级步骤作为起点。
在继续迁移之前，您需要广泛了解将要迁移的内容、系统和功能。 思考范围不要局限于功能和服务列表。 检查您的组织使用的流程和工作流。 哪些信息对您的任务至关重要，或者需要哪些能力或技能才能维护信息？
尽管现有系统的状态可能与目标系统的设计完全不同，但了解现有系统如何以及为何以这种方式构建非常重要。 可了解已部署技术及其配置，深入了解用户与系统的交互方式以及在迁移完成后用于预期与系统的交互方式。
即使迁移不是迫在眉睫，也要制定明确的时间表并遵守该时间表。 使用成功标准创建里程碑，以衡量您是否满足计划以及迁移的每个阶段是否成功。 计划足够的时间来测试工作流，验证目标系统是否可验收，并向员工传授相关知识，让他们知道如何将工作流转移到新模式。
明确规定迁移的不同步骤和部分的负责人。 考虑实现这一目标所需完成的方法不够面命 - 这不仅仅是实施技术和移动内容，而是了解它如何影响组织中的每个人。 所需的角色将包括从召开初始会议到收集利益相关方反馈、完成新系统培训以及在完成设计、实施和测试系统后指导将进行的变更管理程序的方方面面。
在完成上述步骤后，即可开始完成清单，达到您认为可以提供给审计人员的细节层次。 不应让任何用户因对其至关重要的小细节被忽视而感到被遗漏。 确定系统中包含的内容类型、用户使用的配置和 URL 以及安装的软件组件都将帮助您设计迁移方法，并增加对迁移成功的信心。
通过更深入地了解需要迁移的每一条数据、用户、工作流和流程，您应该拥有设计新系统所需的许多组件。 允许架构师投入时间和精力从他们可能需要合作的所有相关人员那里收集需求，并允许他们仔细记录新的目标系统。 请注意目标环境中的所有重大差异，例如域更改、身份验证更改、新安全规则等。
在企业迁移过程中，可以采用多种不同的技术方法。 某些方法使用 ArcGIS Enterprise 即用型功能，例如 WebGIS DR 工具或加入站点方法。 其他迁移可能需要更多手动方法（例如 Python 脚本）来移动内容。 所需方法取决于具体的迁移条件以及源环境和目标环境之间的差异。
最后，一定要记录迁移计划的方方面面，以供后续参考。 本文档是迁移期间的路线图，应说明为成功完成迁移而需要进行的优先活动。 在迁移过程中，该计划可用于根据计划追踪进度，向利益相关方报告进度，并验证所有步骤是否已完全完成。
准备好计划后，即可开始采取行动。 到目前为止，您采取的所有步骤都应该清楚地说明需要进行哪些活动、操作顺序以及将用于评估迁移是否成功的措施。 按照以下步骤指导您制定一些关键步骤。
从现有系统开始。 确保对源系统上的数据、基础设施、应用程序或所需的任何其他内容的更改都已准备就绪。 这包括创建数据和 VM 的副本和备份。 您可能还希望将源系统设置为只读配置，以便用户在迁移过程中无法创建新内容。
理想情况下，请花时间清理此系统中的内容。 如果可以从源系统中移除不需要或未使用的内容，则将减少迁移量，并且对用户的影响时间将缩短，无需完全访问权限。
使用在规划阶段构建的系统设计来部署目标架构。 在部署目标系统后，一定要运行正常的环境验证步骤，确保系统按预期运行。 要确定基准功能正常运行，建议执行从浏览器或桌面连接到 ArcGIS Enterprise、创建 Web 地图或应用程序、注册企业级地理数据库以及发布服务等检查。 从源系统迁移少量代表性测试数据将有助于您执行这些步骤。 请注意，对于某些方法（如 WebGIS DR 迁移），可以将目标系统配置为只能在目标计算机中完全访问或正常运行，并不是所有用户都能访问。
使用您在规划阶段选择的方法开始将用户、群组和内容从源系统迁移到目标系统。 确保在此过程中经常进行检查，并记录迁移失败或内容问题的所有实例。 如果您需要回滚迁移的任何部分，这些说明将至关重要。
与在最后一步中迁移到新系统的一些现有用户合作，让他们使用新系统验证其工作流和流程是否按预期运行，以及其所有内容是否显示且正确。 将此过程设置为迭代过程 - 一旦具有相似工作流和需求的群组验证了他们可以按预期工作，就可以引入一个新群组。 尝试尽可能减少变量，这样在遇到问题时，会更容易确定来源。
有时，在不进行任何现代化的情况下按原样从旧系统迁移到新系统更有意义。 例如，如果您想在升级已部署的 ArcGIS Enterprise 版本之前确保用户的工作流仍可在新的云环境中工作。 如果是这样，在验证用户、内容和工作流后，您可以开始升级或添加在初始实施期间无法处理的任何技术。 之后，请花时间与您的用户一起重新验证工作流。
另一种常见的迁移方法使用迁移窗口作为升级系统的机会 - 迁移完成后（在软件的同一版本中），可以在用户停机期间完成升级，将升级和迁移合并为一个过程。
到目前为止，不仅应该记录流程的每个步骤以供参考，而且您还需要记录您将采取的任何新操作和维护步骤以及它们将如何执行。 您打算遵循的监测、升级、修补、测试、调整和监管计划等任务，以确保系统继续按预期运行。
现在一切就绪后，您可以进行您仍计划进行的任何其他知识传授、培训或变更管理活动。 这些活动可以面向用户、使用者、管理员或利益相关方。
此时，您应该需要一个新的操作系统来满足组织不断增长的需求。 如前所述，迁移通常与现代化齐头并进。 不要将此过程视为已完成，而应将其视为 GIS 现代化持续过程的开始。 看看您在完成迁移后的未来会怎样，并考虑随着时间的推移可以进行哪些增强以使您的系统保持最新状态。