将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
同时运行两家服务商的检查清单
同时运行两家服务商通常是迁移期间有意为之的临时状态，而不是长期架构，但它需要足够的结构，才不会变成散落在代码库各处、令人困惑的条件逻辑。一份检查清单有助于让这个阶段保持简短、目的明确。
在开始向第二家服务商发送真实流量之前：
- 确认两家服务商的响应结构都已映射到一个共享的内部数据结构，这样无论某个请求实际由哪家服务商应答，您的应用代码都从同一种规范化格式中读取数据
- 预先确定分流逻辑：按流量百分比、按特定端点、按特定客户群体，或采用影子模式，即调用第二家服务商，但其结果只记录日志、不实际使用
- 设置单独的日志或标记，以便事后能分辨任一请求由哪家服务商提供，这在出现问题、需要知道先从哪里排查时极为重要
在两家服务商同时上线期间：
- 定期比较两者的错误率和响应时间，而不是只在开始时比较一次，因为其表现可能在几天或几周内发生变化，而单次初始测试会漏掉这些变化
- 留意两家服务商对同一输入给出的实际结果差异，并在两者不一致时有明确的决策流程，而不是简单地假定其中一家就是对的
- 持续记录在两者之间表现明显不同的请求模式，因为这些恰恰是在停用旧服务商之前最值得深入测试的情况
在停用原服务商之前：
- 确认每一条可能调用旧服务商的代码路径都已经在新服务商上实际运行过，而不只是常见情况
- 检查是否存在假定旧服务商始终可用的硬编码回退逻辑，因为双服务商阶段有时会留下没人记得删除的回退代码
- 为关闭旧服务商设定一个具体日期，而不是让双服务商阶段无限期拖延下去，因为没有终点的过渡往往永远不会真正结束
My Geocode 的兼容主机正是为此而建：如果您要迁出的服务商已有对应的兼容主机，这个流程的前半部分，即响应结构规范化，基本上就不再需要，因为响应结构与原服务商完全相同，您现有的规范化代码（如果有的话）也会继续照常工作。全部 17 个兼容主机的列表见 /compatibility/。每个请求还会携带配额响应头，如 X-Quota-Limit、X-Quota-Used、X-Quota-Free-Remaining 等，文档见 /docs/rate-limits/；无论评估的第二家服务商是哪一家，这些响应头对上面的对比日志步骤都很有用。
做得好的双服务商阶段应当简短、监控完善，并在计划日期结束。做得不好，它就会变成一个永久存在、令人困惑的固定环节。两者的区别几乎完全在于，在时间压力下，像这样的检查清单是被认真执行还是被跳过。