--- title: "Migrations" canonical: "https://aifitnessapi.com/migrate" type: "cluster-index" pages: "10" last_reviewed: "2026-07-20" publisher: "AIFitnessAPI" --- # Migrations > 10 pages. Each entry below shows the question the page owns, followed by its answer capsule. ## How to migrate from Google Fit to Health Connect - Question: migrate google fit to health connect - HTML: https://aifitnessapi.com/migrate/google-fit-to-health-connect - Markdown: https://aifitnessapi.com/migrate/google-fit-to-health-connect.md - Last reviewed: 2026-07-20 Google is winding down the Google Fit REST and Android APIs, and the Android successor is Health Connect. The fundamental shift: Google Fit was cloud/REST so a backend could read it server-to-server, but Health Connect is an on-device store with no server endpoint. If you read Fit from your backend, you must re-architect to read on-device in the app and sync to your server yourself, or use an aggregator. This is a real re-integration, not a config swap: new OS permission model, field-by-field data re-mapping, and users must reconnect. Fit reportedly froze new sign-ups in May 2024 and is stated to be supported only through the end of 2026 (verify). ## Migrating from the Fitbit Web API to the Google Health API - Question: fitbit web api google migration - HTML: https://aifitnessapi.com/migrate/fitbit-web-api-to-google-health - Markdown: https://aifitnessapi.com/migrate/fitbit-web-api-to-google-health.md - Last reviewed: 2026-07-20 As Fitbit and Google accounts consolidate, the legacy Fitbit Web API is being retired in favor of the new Google Health API, a cloud REST API that uses Google OAuth 2.0 with a new console, schema, and response format. Treat it as a real re-integration: the biggest gotcha is that your existing Fitbit tokens almost certainly do not transfer, so every user must re-sign-in with a Google Account and re-grant permissions. This migration is announced and in progress as of 2026, and the specific dates come from vendor and community notices, so verify everything against current Fitbit and Google developer notices before you plan a cutover. ## Adding Android to a HealthKit app - Question: add android support healthkit app - HTML: https://aifitnessapi.com/migrate/add-android-to-healthkit-app - Markdown: https://aifitnessapi.com/migrate/add-android-to-healthkit-app.md - Last reviewed: 2026-07-20 HealthKit is iOS-only and on-device, so there is no cloud API to extend to Android; the Android counterpart is Health Connect, also on-device, and there is no single official cross-platform SDK that speaks both. Adding Android is a real second integration: you either build two native paths behind your own normalization layer or adopt an aggregator that abstracts both. The biggest gotcha is that the platforms are not equivalent, so 'support both' always means a mapping layer for differing data types, units, and permission models, not a flag flip. ## Consolidate wearables: replace direct integrations with one aggregator - Question: replace direct integrations with aggregator - HTML: https://aifitnessapi.com/migrate/consolidate-wearables-with-aggregator - Markdown: https://aifitnessapi.com/migrate/consolidate-wearables-with-aggregator.md - Last reviewed: 2026-07-20 Consolidating several per-vendor integrations (Fitbit, Garmin, Oura, WHOOP) behind one aggregator like Terra, Junction (formerly Vital), Rook, or Spike collapses many auth flows and schemas into one integration and one normalized webhook stream. It is a real re-integration, not a flag flip: you re-map fields, some providers still need your own approved credentials, and every user must re-authorize through the aggregator's connect flow. Run the aggregator in parallel with your existing integrations, back-fill within each provider's cap, and cut over provider-by-provider with a rollback path. ## Migrate from an aggregator to direct provider integrations - Question: move from aggregator to direct api - HTML: https://aifitnessapi.com/migrate/aggregator-to-direct-integration - Markdown: https://aifitnessapi.com/migrate/aggregator-to-direct-integration.md - Last reviewed: 2026-07-20 Leaving an aggregator means integrating each provider directly: you register your own developer apps, re-map from the aggregator's normalized schema back to each provider's raw schema, and every user must re-consent onto your own OAuth. The biggest gotcha is that you take back all the maintenance the aggregator absorbed - per-provider auth, token refresh, schema drift, webhooks, and approval renewals - for each provider you bring in-house. It is a real re-integration, so go provider-by-provider, run both paths in parallel, and keep the aggregator as rollback. ## How to switch from one health data aggregator to another - Question: switch health data aggregator - HTML: https://aifitnessapi.com/migrate/between-health-data-aggregators - Markdown: https://aifitnessapi.com/migrate/between-health-data-aggregators.md - Last reviewed: 2026-07-20 Switching aggregators (for example Terra to Junction (formerly Vital), Rook, or Spike) is a real re-integration, not a config swap. Each aggregator has its own normalized schema, connect flow, and webhook signatures, so you re-map fields and rewire your handler. The biggest gotcha: grants and refresh tokens do not transfer, so every user must reconnect. Run both in parallel and migrate in waves. ## Migrate from polling to webhooks for a fitness API - Question: migrate polling to webhooks fitness api - HTML: https://aifitnessapi.com/migrate/polling-to-webhooks - Markdown: https://aifitnessapi.com/migrate/polling-to-webhooks.md - Last reviewed: 2026-07-20 Moving from polling to webhooks means the provider pushes an event when data changes instead of your backend polling on a timer. The biggest gotcha: many providers send a notification with an object id, not the full data, so you still fetch the record. It is a real re-integration - a secured HTTPS endpoint, signature verification, a queue, idempotency, ordering guards, and a fallback poll - not a flag flip. Run polling and webhooks in parallel and keep a low-frequency poll as a permanent safety net. ## Adapting Your Integration to Strava's API Changes - Question: strava api changes 2024 migration - HTML: https://aifitnessapi.com/migrate/adapt-to-strava-api-changes - Markdown: https://aifitnessapi.com/migrate/adapt-to-strava-api-changes.md - Last reviewed: 2026-07-20 Strava has tightened its API and Developer Program in changes rolling out from 2024 onward, so a live integration needs to be brought back into compliance rather than left as-is. Re-read the current developer agreement, re-audit every field you store or display, confirm athlete consent shows in your UI, and re-check rate limits and the one-subscription-per-app webhook constraint. The biggest gotcha: routing Strava data through third-party intermediary platforms may no longer be supported, so an aggregator-mediated setup can require a direct rebuild. Treat it as a real re-integration and verify every specific against the current Strava developer agreement and API Policy. ## Keep Users Connected During a Fitness API Migration - Question: migrate fitness api without losing users - HTML: https://aifitnessapi.com/migrate/keep-users-connected-during-migration - Markdown: https://aifitnessapi.com/migrate/keep-users-connected-during-migration.md - Last reviewed: 2026-07-20 Moving a fitness or health integration to a new source is a real re-integration, not a flag flip. The biggest gotcha is that connections do not transfer: OAuth grants and refresh tokens are bound to your old app or aggregator, so every user must re-authorize the new one. Keep users connected by running old and new in parallel, shipping a re-consent flow, migrating in waves, and holding rollback until continuity is proven. ## Migrate off a deprecated fitness API - Question: migrate off deprecated fitness api - HTML: https://aifitnessapi.com/migrate/migrate-off-a-deprecated-fitness-api - Markdown: https://aifitnessapi.com/migrate/migrate-off-a-deprecated-fitness-api.md - Last reviewed: 2026-07-20 Migrating off a deprecated fitness or health API is a real re-integration, not a config swap: you adopt a successor with a new data schema and usually a new auth model, and most users must reconnect because tokens do not carry over. The biggest silent gap is historical data, which is provider-capped and often not fully recoverable. Run the successor in parallel with a rollback path, migrate users in waves, and decommission only after the new path is validated. Verify the vendor's current timeline and data-type coverage before you cut over.