Google Places API (Legacy) Is Frozen: What EU Developers Should Do Before the Deprecation Clock Starts

Google froze the legacy Places API in March 2025. It still works, but it will not receive new features, and deprecation is coming. For EU developers, the migration decision is more complicated than Google's documentation suggests.

In March 2025, Google quietly restructured its mapping platform in ways that created real urgency for developers, even if the messaging was soft. The legacy Places API, the Directions API, and the Distance Matrix API were all reclassified as "Legacy services." They still work. They will keep working until Google announces a deprecation date. But they have been frozen.

No new features. No architectural improvements. Volume discounts capped at the 100,000+ tier, below what larger applications need. And somewhere in the future, a deprecation announcement with 12 months notice attached.

For most developers, the question is not whether to migrate. It is when, and to what.

For EU developers specifically, the calculus is different. The migration decision involves not just API compatibility and pricing, but GDPR compliance, data residency, and the legal risk of US infrastructure that Google's own documentation does not fully address.

This guide covers what changed, what the migration involves, and what questions EU teams should be asking before they commit to a direction.

What Google Changed in March 2025

The March 2025 restructuring had two distinct components that many developers conflated.

Pricing restructure: Google replaced the $200/month flat monthly credit with per-SKU free tiers. Instead of a single credit that could be applied to any API combination, each API type now has its own free tier:

• Geocoding API: 10,000 free events/month, then $2-7 per 1,000
• Maps JavaScript API: 10,000 free events/month
• Places API (New): free tier per request type
• Routes API: free tier per route type

For developers who were using a single API heavily under the old $200 credit, the new model can mean paying more. For developers spread across multiple API types, the per-SKU free tiers may actually reduce costs. The only way to know is to audit your current usage against the new SKU structure.

Alongside the pricing change, Google launched subscription plans: Starter at $100/month (50,000 combined calls), Essentials at $275/month (100,000 combined calls), and Pro at $1,200/month (250,000 combined calls). These plans are meant to give predictability at scale but add another layer of complexity to cost projection.

API deprecation designations: Separately, Google designated three APIs as Legacy services:

• Places API (Legacy): replaced by Places API (New)
• Directions API: replaced by Routes API
• Distance Matrix API: replaced by Routes API with computeRouteMatrix

The Legacy designation means these APIs receive no new features and are not eligible for the new expanded volume discount tiers. They are in maintenance mode.

What Places API (New) Actually Changes

The Places API (New) is not a drop-in replacement. It has a different request format, different response structure, and different field selection model.

The most significant change is field masking. The legacy API returns a fixed response structure. The new API requires you to specify which fields you need via a field mask header. This reduces unnecessary data transfer and means you only pay for the fields you request, but it also means every API call in your codebase needs to be updated with explicit field masks.

Key differences developers encounter during migration:

Request format: The new API uses POST requests with a JSON body rather than GET requests with query parameters. If your integration constructs URL-based calls, every call needs to be restructured.

Response structure: Field names have changed. formatted_address becomes formattedAddress (camelCase). place_id becomes id. The geometry object is restructured. Response parsing code needs auditing throughout.

New features only in Places API (New): Generative AI summaries, new data fields for EV charging stations, fuel prices, accessibility details, and improved autocomplete suggestions. If you need any of these, you have to migrate.

Photo handling: The photo reference format has changed. Photo URLs generated by the legacy API will eventually stop working, so any cached photo references need to be regenerated.

Google provides migration guides, but the practical experience is that migration is a meaningful engineering task, not a configuration change. Teams typically budget one to four weeks depending on integration complexity.

The Routes API Migration (Separate but Related)

The Directions API and Distance Matrix API follow a similar pattern. The replacement is the Routes API, which uses a different request/response format and offers features the legacy APIs do not: traffic-aware routing, route modifiers, support for two-wheelers, and fuel efficiency optimization.

The Routes API also costs differently. The legacy Directions API priced per element (origin-destination pair). The Routes API prices per route request and per element in matrix requests. For applications making high volumes of matrix requests, costs may change significantly.

If you are migrating Places API, it is worth planning the Routes API migration at the same time rather than running two separate migrations. The parallel effort is more efficient than sequential migrations that each require their own testing and deployment cycles.

The EU-Specific Considerations

This is where the migration decision becomes more nuanced for European developers than Google's documentation suggests.

GDPR and Cross-Border Data Transfers

Google Maps Platform is US infrastructure. When a user's browser makes a request to the Places API or loads a map, that request routes through Google's US-based servers. Under GDPR, this is a cross-border data transfer.

The current legal basis for these transfers is the EU-US Data Privacy Framework, which replaced the Privacy Shield agreement invalidated by the Schrems II ruling in 2020. The DPF has been legally challenged and its long-term stability is not guaranteed. For companies in regulated industries (healthcare, fintech, legal services, government-adjacent applications), continued reliance on US infrastructure is an ongoing compliance conversation that requires monitoring.

Using Google Maps APIs also requires cookie consent for the JavaScript API in some implementations, since user IP addresses and device identifiers are sent to Google. For applications that want to load maps without triggering a consent banner, US-hosted infrastructure creates a structural problem.

Google updated its Maps Platform EEA Terms of Service in 2025 to apply specifically to EU billing addresses. Developers should review the updated terms against their DPA requirements.

Compliance Simplification as Migration Trigger

For many EU teams, the March 2025 changes provided a practical trigger to re-evaluate whether to stay in Google's ecosystem or move to an EU-hosted alternative.

The business case for re-evaluation is straightforward: if you are going to invest engineering time in a migration anyway (legacy Places API to Places API New), the marginal additional effort to migrate to a different provider is often smaller than it appears. The API endpoint changes, field mapping work, and testing cycles are largely the same whether you are migrating to Google's new API or to a third-party alternative. The difference is in what you get when you finish.

An EU-hosted mapping API eliminates the GDPR cross-border transfer concern entirely. All requests stay within the EU. No SCCs to negotiate, no DPF reliance, no cookie consent required to load a map. For companies that have recently completed GDPR audits or are anticipating one, this simplification has real organizational value.

Evaluating Whether to Migrate Within Google or Switch Providers

The honest framework for this decision has four parts.

1. Audit your current API usage

Before making any decision, map every Places API call, Directions API call, and Distance Matrix API call in your codebase. Count the volume per endpoint type. Map that to both the Places API (New) pricing model and to equivalent endpoints in candidate alternative providers.

The cost comparison only makes sense with real usage data. Ballpark estimates based on total request volume are not sufficient because different APIs within the same provider are priced differently.

2. Evaluate GDPR exposure

Ask your legal or compliance team how much ongoing risk the US infrastructure dependency represents for your specific context. For a SaaS product with enterprise EU customers who have DPAs in place, the risk level is different than for a consumer application processing sensitive personal data.

If compliance simplification is valuable, assign it a cost. The internal legal overhead of maintaining SCCs, monitoring DPF stability, and handling customer compliance questionnaires is real work with real cost.

3. Assess migration effort for each path

Migrating to Places API (New) within Google: estimate based on your integration complexity. Field masking changes, request restructuring, response parsing updates. Typically one to four weeks of engineering effort.

Migrating to a third-party alternative: similar engineering scope. Endpoint URL changes, parameter differences, response format differences. For teams already using MapLibre GL JS as their rendering layer (the open-source fork of Mapbox GL JS), the rendering layer stays the same. Only geocoding, search, and routing calls change.

4. Consider what you get on the other side

Places API (New) gives you access to Google's latest features: better autocomplete, generative AI summaries, expanded place data. Google's data coverage is unmatched globally.

EU-hosted alternatives like MapAtlas give you GDPR compliance by design, EU data residency, and in some cases AI search visibility tooling that Google's APIs do not provide. For applications in real estate, hospitality, or logistics where AI discoverability of location pages matters, the AI visibility layer is a meaningful differentiator.

Neither path is universally correct. The right answer depends on your compliance requirements, pricing sensitivity, and what features matter most to your application.

What to Do Right Now

Regardless of which migration path you choose, several actions make sense immediately:

Audit and document your current API surface: Know exactly which legacy endpoints you use, how often, and what data fields you depend on. This information is needed for any migration decision.

Run the pricing comparison with real numbers: Use your actual usage data to compare the legacy pricing, Places API (New) pricing, and alternative providers. Do this at your current volume and at 2x your current volume.

Check your GDPR documentation: Review your current DPA with Google, your SCCs or DPF reliance, and your cookie consent implementation. Understand your current legal position before changing it.

Do not migrate under time pressure: The legacy API still works. It is frozen, not broken. Make the migration decision with clear data and adequate engineering runway rather than rushing because of perceived urgency. The deprecation announcement will give you 12 months notice.

Set a decision deadline: "When Google announces deprecation" is not a plan. Set an internal decision point for which migration path you are taking, ideally within the next quarter.

If you want to compare what EU-hosted mapping APIs actually look like in terms of API surface, pricing, and migration effort, MapAtlas covers geocoding, address autocomplete, routing, and map tiles under a single pricing model with EU data residency. The pricing page shows current tier structure, and the free tier (10,000 requests per month for most APIs, 25,000 for geocoding) lets you test the integration before making a commitment.

Frequently Asked Questions

When will Google deprecate the legacy Places API?

Google has not set a final deprecation date as of early 2026. The legacy API was frozen in March 2025 and no longer receives new features. Google's policy is to provide at least 12 months notice before deprecation. Treat migration as urgent but not emergency.

Is the Places API (New) more expensive than the legacy Places API?

It depends on your usage pattern. The new per-SKU free tiers benefit some usage profiles and hurt others. Map your current API calls to the new SKU structure with your actual usage data before drawing conclusions.

Do I also need to migrate from the Directions API?

Yes, if you want new features and better volume discounts. The Directions API and Distance Matrix API were both designated Legacy services in March 2025. The replacement is the Routes API, which requires its own separate migration evaluation.

What is the GDPR risk of continuing with Google Maps APIs as an EU developer?

Google Maps Platform uses US infrastructure, which requires cross-border data transfer mechanisms under GDPR. The current basis is the EU-US Data Privacy Framework, which has been legally challenged. For regulated industries, this is an ongoing compliance risk that requires monitoring.

How long does migrating to an alternative provider take?

The engineering effort is similar to migrating within Google: one to four weeks depending on integration complexity, mostly spent on endpoint updates, parameter differences, and response format testing. Teams using MapLibre GL JS for rendering have the lightest migration path since the rendering layer stays the same.

Conclusion

The March 2025 changes put a clock on legacy Places API usage without starting the countdown officially. The API still works. The deprecation date has not been announced. But the direction is clear, and the migration will be less painful with adequate planning than with urgency.

For EU developers, the migration moment is also an evaluation moment. The engineering effort to change API endpoints is largely the same whether you are staying within Google or moving to an EU-hosted alternative. The meaningful difference is what you carry forward: Google's comprehensive global dataset and latest features, or GDPR compliance by design, simpler pricing, and EU data residency.

That is a decision worth making deliberately, with real usage data and a clear view of your compliance requirements, rather than defaulting to the path of least immediate resistance.

Related reading:

• Google Maps API alternatives for EU developers
• EU developer's guide to GDPR-compliant map APIs
• Google Maps API pricing 2026: what you actually pay
• Switching from Google Maps API: what EU developers choose instead
• Address autocomplete API: how it improves checkout conversion