将 Zapier 或 Make 自动化流程迁移到新的地理编码主机
基于地理编码步骤构建的无代码自动化流程，需要与自定义代码不同的迁移方法。下面介绍如何完成这种切换。
在迁移过程中处理响应结构差异
即使是匹配得最仔细的替代服务商，也至少会在一些细小的方面与原服务商有所不同，而在这些差异出现在生产环境之前发现它们，与在客户报告问题之后才发现，是截然不同的两回事。采用结构化的方法比较响应结构，可以及早、低成本、平稳地发现其中的大部分差异。
一个有用的起点是区分三类差异，因为每一类都需要不同的应对方式：
字段存在与否的差异。您的代码读取的某个字段，可能在一家服务商的响应中存在，而在另一家的响应中缺失，或者只在特定条件下出现。这是最容易通过静态比较发现的一类：针对同一输入，从每家服务商各取一个示例响应，直接比较字段列表。
字段类型或格式的差异。同一个概念上的值可能有不同的表示方式：坐标可能是两个独立的数值字段，也可能是一个合并的字符串；置信度分数可能是 0 到 1 之间的数字，也可能是一个类别（“high”、“medium”、“low”）；时间戳也可能采用完全不同的格式。要发现这些差异，需要读取实际的值，而不仅仅是字段名。
字段名相同但语义不同。这是最难的一类：两家服务商使用完全相同的字段名，但含义却有细微差别，例如一个“accuracy”字段，一家服务商根据地址组成部分的匹配情况打分，而另一家则基于完全不同的内部方法打分。仅靠比较字段名是发现不了这类差异的；这需要理解某个值在每个系统中实际代表什么，通常需要仔细阅读两家服务商的文档，而不是假定相同的名称就意味着相同的含义。
一个实用的流程是：取一组有代表性的真实历史请求样本，最好至少覆盖您最常见的请求模式和已知的棘手边缘情况，分别发送给旧服务商和新服务商，然后系统地比较结果，而不是凭肉眼看几个例子。将这种比较自动化，哪怕只是一个标记出任何结构差异或显著数值差异的简单脚本，对于任何稍具规模的集成来说都值得花时间搭建。
My Geocode 的兼容替换主机专门针对各自复刻的服务商，将前两类差异降到最低，除版权、条款和隐私声明文字外，字段的存在与格式都完全一致，每个主机的说明见 /docs/compatibility/。这样剩下的就是第三类，即相同字段名下的语义差异，即使使用兼容替换主机，这仍然是主要值得直接测试的内容，因为格式上的一致从不能完全保证底层方法的一致。
在认定迁移完成之前，为这项比较工作预留真正的时间，而不是把少数常见地址测试成功就视为足够，是避免那类细微数据质量问题最可靠的方法之一：这类问题往往需要数周才会被注意到，而追溯到真正的原因则需要更长时间。