Skip to main content

​
Can I run Google and HERE in parallel?

Short answer: Yes, and you should — both as a migration technique and, for many products, as the permanent architecture.

​
During migration: shadow-write

The primary serves the user. The shadow result is discarded.
The shadow call must be asynchronous and fire-and-forget. If it can affect production latency, you have built a second point of failure to test the first.
Feature-flag per endpoint, not per user. A percentage rollout across a routing engine gives you two populations with different route quality and no way to attribute an incident. A rollback should be one flag, one surface, no deploy. Compare offline, against ground truth. Not against each other. Two wrong answers can agree. Keep both live for at least one full business cycle after cutover. Two invoices for a month is cheaper than one incident. You’re not testing the happy path — you’re waiting for the edge case that only occurs on the last Friday of the month.

​
Permanently: the hybrid

The best architecture for many products is both.Google for consumer-facing place search and autocomplete. HERE for routing, matrix operations, batch geocoding, and truck constraints.Nothing requires vendor monogamy, and the split follows the strengths cleanly.
Why: Google’s business POI database — hours, reviews, photos, categories — is categorically better than HERE’s. Placematic sells HERE. We’d rather you know now than after a migration. Why: HERE expresses the commercial vehicle constraints Google’s Large Vehicle Routing does not — weight per axle group, ADR tunnel category, radioactive cargo — and covers 200+ countries against Google’s 48 contiguous states. It also returns toll cost for the described vehicle, which Google documents as unsupported. Document the split as a decision, in writing, before someone frames a deliberate hybrid as a failed migration.

​
What running both costs

Two contracts. Two invoices. Two support paths. Two free tiers that don’t pool. Real overhead. For a small team it may exceed the benefit. For a fleet platform where the map is customer-facing and the routing is safety-critical, it does not.

​
The one thing you must not do

Never fail over from HERE truck routing to Google Large Vehicle Routing.This got more dangerous in August 2026, not less. An unconstrained fallback produced obviously wrong routes — a truck sent under a low bridge fails loudly. A partially-constrained fallback produces plausible ones. If legality depends on axle-group weight, tunnel category or a cargo class the fallback cannot express, the route looks correct, passes review, and is illegal.Refuse to route instead. Assert field-level parity in the facade, not merely that a provider responded. A dispatcher calling operations is a better outcome than a driver following a route through a low bridge.

​
What genuinely fails over

  • Tiles. A CDN with a secondary origin. Users see a map.
  • Geocoding. A cached result, or a stale coordinate with a warning.
  • Serviceability checks. Materialized polygons in your own database. Neither vendor being up is relevant.

​
Common misconceptions

“A hybrid is a failed migration.” It’s a decision. Write it down before someone else characterizes it. “Dual-running is expensive.” Shadow traffic doubles call volume for its duration. Budget for it, and say so. “I’ll compare Google’s answer to HERE’s.” Compare both against telematics ground truth. Two wrong answers can agree. “Percentage rollout is standard practice.” Standard for buttons. Wrong for routing engines.

Google Migration Architecture

Shadow-write, per-endpoint flags, tested rollback.

Migrating One Endpoint

The shadow implementation, in code.

HERE vs Google Maps

Where each genuinely wins.

How do I validate the migration?

Ground truth, distributions, gates.
Need production HERE API keys or implementation support? Placematic is an official HERE Technologies reseller and implementation partner. Talk to us.