将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
在迁移任何内容之前先规划回滚
回滚计划是迁移中这样一个部分：如果做得好，就没有人需要用到它，这也正是它在时间紧张时往往被跳过的原因。跳过它是一个错误，恰恰因为需要回滚却没有回滚计划的代价，远高于准备了一个最终没用上的计划的代价。
一个好的回滚计划的出发点是假设：无论您事先测试得多么彻底，新服务商至少会在某一方面表现得与旧服务商不同，而且是您没有预料到的。这不是悲观，只是对与外部系统集成通常情况的如实描述。围绕这个假设来规划，而不是寄希望于测试已经发现了一切，才能制定出更好的计划。
位置数据服务商切换的回滚计划应涵盖：
- 快速切换机制。无论是功能开关、环境变量，还是在请求时读取而不是固化在已部署构建中的配置值，旧服务商的凭据和端点都应在切换后的某个明确时间窗口内保持有效，并且无需部署代码即可重新启用
- 明确的触发条件。提前决定具体什么情况下应该回滚：错误率超过某个阈值、某一类请求失败，或者用户投诉达到一定数量，而不是在压力之下、没有共识标准的情况下临时做决定
- 回滚负责人。由一个人或一个小组明确负责做出回滚决定，这样决策就不会因为多个人都在等别人拍板而停滞
- 明确的回滚窗口截止时间。无限期地保留两个服务商的凭据有效，就失去了迁移的意义；设定一个具体日期，在此之后永久停用旧服务商的访问权限
由于 My Geocode 的兼容主机完全复现了服务商的请求和响应结构，在基于兼容主机的迁移中，回滚通常只是把配置改回旧的主机和密钥，无需重新部署不同的解析代码，这缩短了真正需要回滚时执行回滚所花的时间。不过，这一点是双向的：这也意味着，值得在规划阶段专门测试一次回滚确实可行，而不是想当然地认为它可行，因为一条未经测试的回滚路径，与根本没有回滚计划并没有实质区别。
还值得决定的是，在您要回滚的那段时间内处理过的数据或请求该如何处理。如果某个批处理任务在夜间针对新服务商运行，而问题直到第二天早上才被发现，那么这批数据是需要重新处理，还是可以接受其中的差异？提前而不是在真正发生事故时决定这一点，可以在本已紧张的时刻少做一个决定。
一个只描述向前推进的迁移计划，从真正意义上说是不完整的计划。回滚这一半，才让迁移从一场单向的赌注变成一个经过深思熟虑、在证据需要时可以干净撤回的决定。