How to migrate from Google Fit to Health Connect

Google is winding down the Google Fit developer platform — both the Google Fit REST API and the Android Fitness (Google Fit Android) APIs — and the Android successor is Health Connect. The single most important thing to understand up front: Google Fit was cloud/account-centric, so a backend could read a user's data server-to-server over REST; Health Connect is an on-device store with no server endpoint. If you previously pulled Fit data from your backend, you cannot just re-point a URL — you read on the device inside your app and sync to your own backend yourself, or use an aggregator. This is a real re-integration: new permission model, field-by-field data re-mapping, and users must reconnect. Every date below is "as of 2026, verify" against Google's live migration docs.

Why you're doing this now

Google stopped accepting new sign-ups for the Google Fit REST and Android APIs (reported as May 1, 2024), and the Fit APIs are stated to be supported only through the end of 2026 before shutdown — the exact day within 2026 is not published, so verify. If your app or backend still depends on Fit, you are on a clock. For the symptom side of this — deprecation warnings, 403s, and shutdown notices — see Google Fit API deprecated. If you are still weighing targets rather than committed to Health Connect, the Google Fit API alternatives page covers the decision; this page assumes you are making the move.

What actually changes

The hardest part is not the code, it is the architecture. Google Fit's REST API has no direct on-device replacement — Google's own FAQ says REST users must choose a different path entirely.

Two things worth calling out. First, there is a separate, newer cloud Google Health API (the same platform Fitbit is moving onto) for server-side use cases — it is a different product from Health Connect, so do not conflate the two. Second, Health Connect's Recording API offers step-only, account-free, battery-efficient step counting on Android, but that is a narrow subset, not a full replacement. For the on-device concept in general, see on-device vs cloud health data. This page is the move, not the setup — the full Health Connect wiring lives in the Health Connect integration guide.

The migration, step by step

1. Inventory your Fit usage. List every REST endpoint and Android Fitness API call, the exact data types and datasources, and whether each read happens on-device or server-side. This map is what the rest of the migration runs on.
2. Split each read by architecture. For every read, decide its new home: on-device Health Connect (mobile reads, you sync to backend), the cloud Google Health API, or an aggregator. Server-to-server reads are the ones that change most.
3. Register for the successor. Set up Health Connect — the Play Console health-apps declaration plus manifest permissions — and/or the Google Health API console. Note that no new Google Fit sign-ups are possible.
4. Map data types field by field. Build an explicit table from each Fit datatype/datasource to its Health Connect record type (for example steps → StepsRecord, sleep → SleepSessionRecord, workouts → ExerciseSessionRecord). Flag anything with no equivalent.
5. Build the on-device read plus sync layer. Add the Health Connect client, request paired READ permissions, and add READ_HEALTH_DATA_HISTORY (for older data) or READ_HEALTH_DATA_IN_BACKGROUND if you need them. Because there is no server endpoint, push the results to your backend yourself.
6. Run old and new in parallel, then re-consent users. Keep Fit live through its 2026 support window while the new path runs alongside, and compare values to validate the mapping. Surface the new Health Connect connection in-app, explain the benefit, and capture the OS permission grant — do not force-disconnect Fit yet.
7. Backfill within limits and test. Pull whatever history the history permission allows, and accept that deep Fit cloud history may not exist on-device — document the gap for users. Test with the Health Connect Toolbox across granted, partially-granted, and denied permission states.
8. Cut over in waves, then decommission Fit. Migrate cohorts with monitoring, keep a rollback path until confidence is high, and turn off the Fit path before end-of-2026.

Gotchas and how to keep users connected

• Tokens and consent do not transfer. There is no silent migration of Fit consent to Health Connect. Every user must re-grant through the OS permission flow, so design the reconnect UX from day one and migrate in cohorts, not a big-bang cutover. The cross-cutting version of this lives in keep users connected during migration.
• Historical data is the silent gap. Health Connect only holds what is on that device or written by connected apps — it is not a backfill of a user's entire Google Fit cloud history. Reading data older than the default window (documented as roughly 30 days — verify current window) requires READ_HEALTH_DATA_HISTORY. Be honest with users about what history survives.
• No server API means sync is your job. Do not architect as if Health Connect gives you a backend endpoint. If server-side reads are core to your product, that is exactly where the cloud Google Health API or a health-data aggregator — which runs an on-device SDK and forwards normalized data to your server — earns its place.
• Coverage is broad but not 1:1. Health Connect spans Activity, Vitals (including HRV and resting heart rate), Sleep with stages, Body Measurement, Nutrition/Hydration, Cycle Tracking, and Wellness — but names, units, and granularity differ from Fit. Verify each type before promising parity.

How much work is this, really

Treat this as a re-integration measured in weeks, not a flag flip — the effort is concentrated in the architecture split (step 2) and the on-device sync layer (step 5), not in the mapping table. The safest path is parallel-run with a rollback path and a wave cutover well before the end-of-2026 sunset. Because Google's dates have moved before and the exact shutdown day is unpublished, confirm the current timeline and history window in Google's official migration docs before you commit a schedule.