Moving from a hosted wearable API to Open Wearables: a migration playbook
Key takeaways
- Moving from a hosted wearable API to Open Wearables is usually a re-integration rather than a data migration. Your history stays where it is, and new data lands in your own Open Wearables deployment from the switch onwards.
- Open Wearables runs in your own cloud account. The provider apps are registered in your name, and your product reads one standard schema from your own database.
- The slowest step is rarely engineering. Provider credentials in your name can take a day or several weeks, so that work starts first.
- Users reconnect once, through your own consent screen, because a connection belongs to the app that requested it. Open Wearables runs the connection flow and the token lifecycle.
- Most teams run the hosted API and Open Wearables side by side, move users in batches, and switch the hosted API off only when the new path is proven. You can run the move yourself or with Momentum.
Who this playbook is for
You run a health or fitness product that reads wearable data through a hosted API today. It got you to market quickly, and it still works. But a question has moved up your roadmap: what would it take to hold the connection to our users' devices ourselves?
The timing is not an accident. In October, Garmin reopened its Connect Developer Program with a clear access model: each company registers its own app and holds its own credentials. Strava's API agreement, in force since June, says a developer may not share its API token with any third party. Add an enterprise customer's security review or a residency requirement, and owning the data layer turns from an idea into a plan.
This playbook walks through that plan for a move to Open Wearables, the open-source platform for wearable and health data that runs in your own cloud. It stays at the level of decisions and sequence, for product leads, CTOs and engineering managers. The technical detail lives in the Open Wearables documentation.
What moving to Open Wearables actually changes
Today, data travels from each provider through a hosted service into your product. The provider apps are registered to that service, the data sits on its schema in its cloud, and your product calls its API.
After the move, data travels from each provider into your own Open Wearables deployment, in a cloud account and region you choose. The provider apps are registered in your name. Everything lands in one standard schema in your own database, with the original provider payload kept underneath if you want it, and your product reads it over the Open Wearables REST API or reacts to its webhooks.
That is why this is usually a re-integration rather than a data migration. You are not exporting years of records and loading them somewhere else. You are building a second path for new data, proving it, and moving users onto it when you are ready. The history you already hold stays where it is.
Five decisions to make before anyone writes code
1. Which providers have to work on day one. List the sources your users actually connect through the hosted API today. The first Open Wearables deployment covers those; others can follow without changing how your product reads the data.
2. Who runs Open Wearables. Your engineers can stand it up from the open-source repository, or Momentum can deploy it into your account and hand it over. The architecture is identical either way. The difference is speed and who carries the operational work afterwards.
3. Which cloud account and region. If a customer contract or a regulator says where health data may sit, this is where you answer it, once.
4. Where users reconnect. Each user authorises your app once. Decide where in your product that happens and what you tell them. It is a product decision as much as an engineering one.
5. What "done" means. Agree the acceptance criteria up front: data on real accounts matches what each provider's own app shows, the parallel run has been stable for an agreed period, and an agreed share of users has moved across.
The move, step by step
Step 1: Map what your product uses today. Start with an architecture audit: which providers, which data types your features depend on, which events your product reacts to, and what has to keep working on the first day. Most products use a smaller slice of the hosted API than they think. The outcome is a written plan that maps each of those to the Open Wearables standard schema and webhooks.
Step 2: Apply for provider credentials in your name. Each provider issues developer credentials to your organisation, and you apply for them directly. Some approve within a day, others take weeks, and it is the usual reason a launch slips. Start here and run everything else in parallel. If you already hold credentials for a provider, the slow part is behind you: bring the client ID and secret, and point them at your deployment.
Step 3: Deploy Open Wearables next to the hosted API. Production and staging go into your own cloud account, defined as infrastructure code in your repository. Nothing about your current integration changes yet, and nobody's users are touched.
Step 4: Connect and validate on real accounts. Connect a handful of test accounts per provider. Open Wearables runs each provider's connection flow and manages the tokens; your team compares what arrives with what the provider's own app shows. Provider quirks surface here, when they are easy to fix, rather than after launch.
Step 5: Point your product at Open Wearables. Switch the parts of your product that read wearable data over to the Open Wearables API and webhooks, behind a flag if you can. Because every provider comes back in the same shape, adding a source later does not change the call.
Step 6: Move users across in batches. Invite users to reconnect through your own consent screen, a cohort at a time. Watch the numbers, fix what surfaces, then widen the next batch.
Step 7: Switch off the hosted API. When the new path is proven and the share of users you agreed has moved, retire the hosted integration. Keep a short window for stragglers, then close it.
Reconnecting users without drama
Reconnection is the part of the move your users actually see. A connection to Garmin, Oura or Whoop belongs to the app that requested it, so moving to provider apps registered in your name means each user authorises once more. Open Wearables handles the flow itself; the experience around it is yours.
- Tell them why. One sentence is enough: you are moving their device connection into your own systems, and it takes a single tap.
- Ask in context. Put the prompt on the screen where they already look at their device data, not in a settings menu.
- Keep it to one tap. The provider's own consent screen does the rest, and your app should return them exactly where they were.
- Track who has not moved. After a week, follow up with users who have not reconnected. After two, decide what happens to their old connection.
Phone-based sources work differently. Apple Health, Health Connect and Samsung Health have no cloud API, so the Open Wearables mobile SDK reads the store on the phone with the user's permission and syncs to your deployment in the background. For those users the step is a permission prompt in your own app.
What happens to historical data
The history you already hold stays where it is, and your product can keep reading it. From the switch onwards, new data lands in your own Open Wearables deployment.
When a user connects, Open Wearables requests history from each provider that offers it. How far back depends on the provider and, for some, on your access tier; for several providers the default is ninety days, and you can request a specific range yourself. For Apple Health, a user's full export can be imported directly, which is how people bring years of history with them.
What to tell your security and compliance team
The conversation is usually shorter than teams expect, because the answers are architectural rather than contractual.
- Where the data sits: in your own cloud account, in the region you chose. You show it by pointing at the account.
- Who can reach it: your team. When Momentum works on your system, it does so under a DPA you sign.
- Whose provider apps they are: yours. The credentials are issued to your organisation.
- What happens if you stop working with Momentum: nothing stops. The deployment is built from infrastructure code in your repository, under an MIT license.
- Certification: Open Wearables runs inside your own certified environment. If you hold SOC 2 or ISO 27001, the deployment can sit within that scope.
How Momentum can help with the move
Open Wearables is open source, and teams run this playbook with their own engineers, the documentation and the community on Discord. If you would rather not carry the move alone, Momentum, the team that builds Open Wearables, can take on as much of it as you need: the architecture audit and migration plan, the deployment in your cloud account with providers onboarded under your credentials, the connection and consent flow in your app, and support while your users move across. After the move, Enterprise support adds an SLA, a named on-call and tested upgrades.
The deployment is yours from the first commit either way. See how a migration to Open Wearables runs, or tell us what you run today.
FAQ
Do all our users have to reconnect?
Yes, once. A connection belongs to the app that requested it, so moving to provider apps registered in your name means each user authorises again. Open Wearables runs the flow; you choose where it appears in your product.
Can we run the hosted API and Open Wearables at the same time?
Yes, and most teams do. It is the safest way to validate the new path on real users before switching the hosted API off.
Do we lose the data we already have?
No. The history you hold stays where it is. New data lands in your own deployment from the switch onwards, and history is requested from providers that offer it as users reconnect.
Do we have to rewrite our product?
Usually not. The parts of your product that read wearable data switch to the Open Wearables API and webhooks. Mapping your current data model to the standard schema is part of the architecture audit.
How long does the move take?
It depends on your providers and on how long their credential approval takes. The architecture audit ends with a timeline for your setup.
Open Wearables
Open Wearables is an open-source platform that connects your application to wearable and health data providers through a single API. One normalized data model, multi-provider support in a single self-hosted deployment, MIT licensed, and health intelligence built in: normalized recovery, sleep, activity and biometric data ready for your product layer.
We offer custom deployment and integration support through Momentum. If your team needs help getting to production faster, we can set up and configure Open Wearables as part of a managed engagement. Let's talk.
Book a demo to see how Open Wearables fits your use case.