Google Maps API-Deprecations im Mai 2026: Eine Migrations-Checkliste für Entwickler

Google verschärft seine Maps Platform seit Jahren, doch die Deprecation-Welle im Mai 2026 ist die bisher folgenreichste. Vier weit verbreitete Features werden aus der Maps JavaScript API entfernt: der Heatmap Layer, die Drawing Library, DirectionsService und DistanceMatrixService. Wer diese in seiner Anwendung nutzt, hat nur noch wenige Wochen, um zu migrieren, bevor der Code aufhört zu funktionieren.

Dies ist keine weiche Deprecation, bei der alte Endpoints jahrelang erhalten bleiben. Google hat harte Removal-Termine gesetzt, und die Developer Console zeigt bereits Warnungen an. Dieser Leitfaden erklärt genau, was sich ändert, warum Google diese Änderungen durchführt und wie jeder Service mit funktionierenden Codebeispielen migriert wird. Wer einen Drop-in-Ersatz benötigt, erfährt hier, wie MapAtlas-APIs den einzelnen deprecated Google-Services entsprechen.

Was wird wann abgekündigt

Die vollständige Zeitleiste der betroffenen Services:

Ein entscheidendes Detail: Google entfernt nicht Routing und Entfernungsberechnungen insgesamt. Es werden die JavaScript-Client-Klassen entfernt, die Entwickler seit über einem Jahrzehnt verwenden, und die Migration zur neueren Routes API erzwungen, einem serverseitigen REST-Endpoint. Es handelt sich nicht um einen einfachen Versions-Bump, sondern um eine architektonische Änderung, die die Routing-Logik vom Browser ins Backend verlagert.

Was dabei bricht

Enthält die Codebasis eines der folgenden Elemente, wird es nach dem Removal-Datum fehlschlagen:

// All of these will stop working in May 2026
const directionsService = new google.maps.DirectionsService();
const distanceMatrixService = new google.maps.DistanceMatrixService();
const heatmap = new google.maps.visualization.HeatmapLayer({ data: points });
const drawingManager = new google.maps.drawing.DrawingManager();

Nach dem Removal werfen diese Konstruktoren Fehler. Es gibt kein Fallback-Verhalten, keine graceful Degradation. Die Karte lädt zwar, aber jedes Feature, das auf diesen Klassen basiert, bricht vollständig weg.

Warum Google diese Änderungen erzwingt

Googles offizielle Begründung lautet Performance und Modernisierung. Die Routes API als Ersatz für DirectionsService und DistanceMatrixService unterstützt neuere Features wie umweltfreundliches Routing, Zweirad-Routing und Mautkosten-Schätzung, die die Legacy-JavaScript-Klassen nicht abbilden können.

Der eigentliche Treiber ist die Preiskontrolle. Durch die Verlagerung von Routing auf eine serverseitige REST-API gewinnt Google eine feingranulare Abrechnung und Nutzungsverfolgung. Der JavaScript-basierte DirectionsService erlaubte clientseitige Batching-Muster, die für Google schwieriger präzise zu messen waren. Die Routes API stellt sicher, dass jede Anfrage durch einen gemessenen Endpoint läuft.

Für Heatmap Layer und Drawing Library drängt Google Entwickler in Richtung Extended Component Library und Drittanbieter-Visualisierungs-Tools wie deck.gl. Das ist Teil eines übergeordneten Musters: Google behält das Core-Map-Tile-Rendering im eigenen Haus und lagert alles andere ans Ökosystem aus.

Die praktischen Auswirkungen für Entwickler sind mehr Backend-Infrastruktur, mehr API-Keys zu verwalten und in den meisten Fällen höhere Kosten pro Request in den neuen Preisstufen.

Migrations-Checkliste

Vor dem Schreiben von Migrationscode sollte diese Checkliste durchgearbeitet werden:

1. Codebasis auditieren

Die Codebasis nach Referenzen auf die deprecated Klassen durchsuchen:

# Find all files using deprecated Google Maps services
grep -rn "DirectionsService\|DistanceMatrixService\|HeatmapLayer\|visualization.HeatmapLayer\|drawing.DrawingManager\|DrawingManager" \
  --include="*.js" --include="*.ts" --include="*.tsx" --include="*.jsx" src/

Jede Datei und Komponente, die diese Services verwendet, ist zu dokumentieren. Dabei ist festzuhalten, ob die Aufrufe clientseitig (Browser) oder in einem server-gerenderten Kontext stattfinden, beispielsweise Next.js API Routes.

2. Nutzungsmuster identifizieren

Für jede Nutzung ist zu dokumentieren:

• Verwendete Travel Modes (Driving, Walking, Cycling, Transit)
• Waypoint-Unterstützung (einfaches A-nach-B oder Multi-Stop-Routen)
• Verarbeitete Response-Felder (Distanz, Dauer, Polyline, Steps, Fare)
• Volumen (Anfragen pro Tag/Monat, für Kostenschätzung)
• Latenzanforderungen (Echtzeit für Endnutzer oder Batch-Verarbeitung)

3. Migrationsziel auswählen

Zwei Optionen stehen zur Verfügung:

Option A: Bei Google bleiben. Von den deprecated JavaScript-Klassen zur neuen Google Routes API (REST) migrieren. Dies erfordert Backend-Änderungen, neue API-Key-Berechtigungen und aktualisierte Abrechnung.

Option B: Anbieter wechseln. Zu einer Drittanbieter-Routing-API migrieren. Da der Integrationscode ohnehin neu geschrieben wird, ist dies der richtige Zeitpunkt, Alternativen zu evaluieren.

4. Parallelumgebung einrichten

Niemals in-place migrieren. Alte und neue Implementierungen mindestens zwei Wochen parallel betreiben und Ergebnisse bezüglich Genauigkeit und Latenz vergleichen, bevor umgestellt wird.

5. Fehlerbehandlung aktualisieren

Die deprecated Services lieferten Fehler über Callback-Funktionen. REST-API-Ersatzlösungen geben HTTP-Statuscodes zurück. Die Fehlerbehandlungslogik muss entsprechend angepasst werden.

API-für-API-Ersatzleitfaden

DirectionsService zu MapAtlas Directions API

Vorher (Google, deprecated):

const directionsService = new google.maps.DirectionsService();

directionsService.route(
  {
    origin: { lat: 52.52, lng: 13.405 },
    destination: { lat: 48.8566, lng: 2.3522 },
    travelMode: google.maps.TravelMode.DRIVING,
    waypoints: [
      { location: { lat: 50.9375, lng: 6.9603 }, stopover: true }
    ],
  },
  (result, status) => {
    if (status === "OK") {
      const route = result.routes[0];
      console.log("Distance:", route.legs[0].distance.text);
      console.log("Duration:", route.legs[0].duration.text);
    }
  }
);

Nachher (MapAtlas Directions API):

const response = await fetch(
  "https://api.mapatlas.com/v1/directions?" +
    new URLSearchParams({
      origin: "52.52,13.405",
      destination: "48.8566,2.3522",
      waypoints: "50.9375,6.9603",
      mode: "driving",
      key: process.env.MAPATLAS_API_KEY!,
    })
);

const data = await response.json();

if (data.status === "OK") {
  const leg = data.routes[0].legs[0];
  console.log("Distance:", leg.distance.text);
  console.log("Duration:", leg.duration.text);
  // Polyline for map rendering
  const polyline = data.routes[0].overview_polyline;
}

Wesentliche Unterschiede:

• REST Endpoint statt einer JavaScript-Klasse. Aufrufe erfolgen vom Backend, nicht aus dem Browser.
• Einfachere Authentifizierung. Ein API-Key im Query-String oder Header.
• Gleiche Response-Struktur. Routes, Legs, Distance, Duration und Polyline sind alle vorhanden.

DistanceMatrixService zu MapAtlas Matrix API

Vorher (Google, deprecated):

const service = new google.maps.DistanceMatrixService();

service.getDistanceMatrix(
  {
    origins: [
      { lat: 52.52, lng: 13.405 },
      { lat: 48.1351, lng: 11.582 },
    ],
    destinations: [
      { lat: 48.8566, lng: 2.3522 },
      { lat: 51.5074, lng: -0.1278 },
    ],
    travelMode: google.maps.TravelMode.DRIVING,
  },
  (response, status) => {
    if (status === "OK") {
      response.rows.forEach((row, i) => {
        row.elements.forEach((element, j) => {
          console.log(`Origin ${i} -> Dest ${j}:`,
            element.distance.text, element.duration.text);
        });
      });
    }
  }
);

Nachher (MapAtlas Matrix API):

const response = await fetch("https://api.mapatlas.com/v1/matrix", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.MAPATLAS_API_KEY}`,
  },
  body: JSON.stringify({
    origins: [
      { lat: 52.52, lng: 13.405 },
      { lat: 48.1351, lng: 11.582 },
    ],
    destinations: [
      { lat: 48.8566, lng: 2.3522 },
      { lat: 51.5074, lng: -0.1278 },
    ],
    mode: "driving",
  }),
});

const data = await response.json();

data.rows.forEach((row: any, i: number) => {
  row.elements.forEach((element: any, j: number) => {
    console.log(`Origin ${i} -> Dest ${j}:`,
      element.distance.text, element.duration.text);
  });
});

Die Response-Struktur ist nahezu identisch. Die Hauptänderung besteht im Wechsel von einer callback-basierten Browser-API zu einer promise-basierten Server-API.

Heatmap Layer ersetzen

Für Heatmap-Visualisierung hängt der Migrationspfad von den Anforderungen ab:

Option 1: MapLibre GL JS mit Heatmap-Layer (Open Source)

import maplibregl from "maplibre-gl";

const map = new maplibregl.Map({
  container: "map",
  style: "https://api.mapatlas.com/v1/styles/streets?key=YOUR_KEY",
  center: [13.405, 52.52],
  zoom: 10,
});

map.on("load", () => {
  map.addSource("heat-data", {
    type: "geojson",
    data: {
      type: "FeatureCollection",
      features: heatmapPoints.map((point) => ({
        type: "Feature",
        geometry: { type: "Point", coordinates: [point.lng, point.lat] },
        properties: { weight: point.weight },
      })),
    },
  });

  map.addLayer({
    id: "heatmap-layer",
    type: "heatmap",
    source: "heat-data",
    paint: {
      "heatmap-weight": ["get", "weight"],
      "heatmap-intensity": 1,
      "heatmap-radius": 20,
      "heatmap-opacity": 0.7,
    },
  });
});

Dies bietet volle Kontrolle über das Heatmap-Rendering und ist nicht von Googles Tile-Servern abhängig.

Option 2: deck.gl HeatmapLayer (Googles eigene Empfehlung)

import { Deck } from "@deck.gl/core";
import { HeatmapLayer } from "@deck.gl/aggregation-layers";

const heatmapLayer = new HeatmapLayer({
  data: heatmapPoints,
  getPosition: (d) => [d.lng, d.lat],
  getWeight: (d) => d.weight,
  radiusPixels: 30,
});

Beide Optionen funktionieren. MapLibre GL JS integriert sich sauber mit MapAtlas-Tile-Styles, während deck.gl auf jeder Basiskarte overlay-fähig ist.

Kostenvergleich: Google Routes API vs. MapAtlas

Die Migration zur Google Routes API ist nicht nur eine Code-Änderung. Sie bringt neue Preise mit sich:

Bei 100.000 Routing-Anfragen pro Monat:

• Google Routes API: ca. 500–1.000 $ (je nach genutzten Features)
• MapAtlas Directions API: ca. 150–250 $

Die Einsparungen summieren sich schnell bei Anwendungen, die Routing mit Geocoding und Entfernungsberechnungen kombinieren. Eine Logistikplattform, die 500.000 Matrix-Elemente pro Monat verarbeitet, zahlt bei Google rund 2.500 $ gegenüber 500 $ bei MapAtlas.

Vollständige Preisdetails unter MapAtlas-Preise.

Code-Migrationsbeispiele: Vollständiges Vorher/Nachher

Ein vollständiges Migrationsbeispiel für eine React-Komponente, die Fahrtrouten auf einer Karte anzeigt.

Vorher: Google Maps DirectionsService in React

import { useEffect, useRef } from "react";

function DirectionsMap({ origin, destination }: {
  origin: google.maps.LatLngLiteral;
  destination: google.maps.LatLngLiteral;
}) {
  const mapRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    const map = new google.maps.Map(mapRef.current!, {
      center: origin,
      zoom: 7,
    });

    const directionsRenderer = new google.maps.DirectionsRenderer();
    directionsRenderer.setMap(map);

    const directionsService = new google.maps.DirectionsService();
    directionsService.route(
      {
        origin,
        destination,
        travelMode: google.maps.TravelMode.DRIVING,
      },
      (result, status) => {
        if (status === "OK" && result) {
          directionsRenderer.setDirections(result);
        }
      }
    );
  }, [origin, destination]);

  return <div ref={mapRef} style={{ width: "100%", height: "400px" }} />;
}

Nachher: MapAtlas Directions API mit MapLibre GL JS

import { useEffect, useRef } from "react";
import maplibregl from "maplibre-gl";

function DirectionsMap({ origin, destination }: {
  origin: { lat: number; lng: number };
  destination: { lat: number; lng: number };
}) {
  const mapRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    const map = new maplibregl.Map({
      container: mapRef.current!,
      style: "https://api.mapatlas.com/v1/styles/streets?key=YOUR_KEY",
      center: [origin.lng, origin.lat],
      zoom: 7,
    });

    map.on("load", async () => {
      // Fetch directions from your backend (or directly if CORS allows)
      const res = await fetch(
        `/api/directions?` +
          new URLSearchParams({
            origin: `${origin.lat},${origin.lng}`,
            destination: `${destination.lat},${destination.lng}`,
            mode: "driving",
          })
      );
      const data = await res.json();

      if (data.routes?.[0]) {
        const coordinates = data.routes[0].geometry.coordinates;

        map.addSource("route", {
          type: "geojson",
          data: {
            type: "Feature",
            geometry: { type: "LineString", coordinates },
            properties: {},
          },
        });

        map.addLayer({
          id: "route-line",
          type: "line",
          source: "route",
          paint: {
            "line-color": "#4A90D9",
            "line-width": 5,
          },
        });

        // Fit map to route bounds
        const bounds = coordinates.reduce(
          (b: maplibregl.LngLatBounds, coord: [number, number]) =>
            b.extend(coord),
          new maplibregl.LngLatBounds(coordinates[0], coordinates[0])
        );
        map.fitBounds(bounds, { padding: 50 });
      }
    });

    return () => map.remove();
  }, [origin, destination]);

  return <div ref={mapRef} style={{ width: "100%", height: "400px" }} />;
}

Backend API Route (Next.js)

// app/api/directions/route.ts
import { NextRequest, NextResponse } from "next/server";

export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url);
  const origin = searchParams.get("origin");
  const destination = searchParams.get("destination");
  const mode = searchParams.get("mode") || "driving";

  const response = await fetch(
    `https://api.mapatlas.com/v1/directions?` +
      new URLSearchParams({
        origin: origin!,
        destination: destination!,
        mode,
        key: process.env.MAPATLAS_API_KEY!,
      })
  );

  const data = await response.json();
  return NextResponse.json(data);
}

Dieses Muster hält den API-Key auf dem Server und gibt nur die Route-Geometrie an den Client weiter.

Migration testen vor der Deadline

Schritt 1: Beide APIs parallel betreiben

Zwei Wochen vor dem Umstieg beide APIs für jede Anfrage aufrufen. Beide Responses loggen und vergleichen:

async function getDirectionsWithComparison(
  origin: string,
  destination: string
) {
  const [googleResult, mapatResult] = await Promise.all([
    fetchGoogleDirections(origin, destination),
    fetchMapAtlasDirections(origin, destination),
  ]);

  // Compare key metrics
  const distanceDelta = Math.abs(
    googleResult.distance - mapatResult.distance
  );
  const durationDelta = Math.abs(
    googleResult.duration - mapatResult.duration
  );

  console.log({
    route: `${origin} -> ${destination}`,
    googleDistance: googleResult.distance,
    mapatDistance: mapatResult.distance,
    distanceDeltaPercent: ((distanceDelta / googleResult.distance) * 100).toFixed(1),
    googleDuration: googleResult.duration,
    mapatDuration: mapatResult.duration,
    durationDeltaPercent: ((durationDelta / googleResult.duration) * 100).toFixed(1),
  });

  // Use MapAtlas result in production, Google as validation
  return mapatResult;
}

Schritt 2: Feature Flags einrichten

Über einen Feature Flag steuern, welche API die Anwendung aufruft. Das ermöglicht sofortiges Rollback bei Problemen:

const useMapAtlasDirections = process.env.FEATURE_MAPATLAS_DIRECTIONS === "true";

const directions = useMapAtlasDirections
  ? await fetchMapAtlasDirections(origin, destination)
  : await fetchGoogleDirections(origin, destination);

Schritt 3: Fehlerquoten monitoren

Nach dem Umstieg folgende Metriken beobachten:

• HTTP 4xx/5xx-Fehlerquoten der neuen API
• Latenzerhöhungen (neuer Anbieter kann andere Antwortzeiten haben)
• Fehlende Felder in Responses, auf die die UI angewiesen ist
• Routen-Genauigkeit für Randfälle (Fährrouten, Mautstraßen, gesperrte Bereiche)

Schritt 4: Lasttest vor Go-Live

Verarbeitet die Anwendung Lastspitzen, z.B. eine Logistikplattform beim morgendlichen Dispatch, sollte die neue API mit dem 2-fachen des Spitzenvolumens lastgetestet werden. MapAtlas bietet eine Sandbox-Umgebung für Lasttests ohne Produktionsabrechnung.

Zeitplan: Was diese Woche zu tun ist

Wer noch nicht mit der Migration begonnen hat, sollte diese Prioritätenreihenfolge einhalten:

1. Diese Woche: Codebasis auditieren. Jede Verwendung der vier deprecated Services identifizieren.
2. Woche 2: MapAtlas-Account einrichten und API-Keys holen. Das Free Tier umfasst 10.000 Anfragen zum Testen.
3. Woche 3: Ersatz für den kritischsten Service implementieren, in der Regel DirectionsService.
4. Woche 4: Verbleibende Services migrieren und Paralleltests durchführen.
5. Vor der Mai-Deadline: Umstellen, Google-API-Abhängigkeiten entfernen, Abrechnung aktualisieren.

Die Migration ist nicht optional. Nach Mai 2026 werden die deprecated Klassen aus der Maps JavaScript API entfernt, und jeder Code, der auf sie verweist, wirft Runtime-Fehler. Wer jetzt beginnt, hat genügend Zeit für ordentliche Tests. Wer bis zur letzten Woche wartet, wird unter Druck in der Produktion patchen.

Für Migrationsunterstützung bietet MapAtlas direkte Entwicklerhilfe. Kontakt über die Kontaktseite oder direkt mit der API-Dokumentation starten, um die Ersatz-APIs gegen die eigenen Anforderungen zu evaluieren.