Portability Without Flattening Meaning
openGym’s synchronization model protects a profile while it remains inside the application, but ownership is incomplete if the data cannot leave in a usable form. This chapter compares four different portability decisions: importing workout history, sharing a plan, restoring a full backup, and moving media with a device or server. The practical goal is to choose the operation that matches what is being moved, while avoiding the common mistake of treating every export as one interchangeable copy of “the data.”
Choose the Operation by What You Are Moving
Importing workout history is an attempt to preserve events. A CSV from another tracker may contain one row per set, a date, an exercise name, and some measured value such as weight, repetitions, distance, or duration. openGym maps headers through normalized aliases so different exporters can describe similar columns without requiring a separate hard-coded importer for every application. It recognizes common exports from FitNotes, Strong, Hevy, and other sources, and it handles dates, units, effort fields, and timed work that arrive in different shapes.
The important design choice is what happens when an imported exercise name is ambiguous. A naïve importer can force the name into the closest built-in exercise and create a clean-looking but wrong history. That is worse than visible incompleteness because the wrong movement may feed future progression, muscle maps, and estimated records for years. openGym matches conservatively. When the name cannot be resolved with enough confidence, the import can create a user-owned custom exercise rather than silently filing the sets under a potentially different lift. The user may need to correct the result, but the ambiguity remains visible and the rows are not simply discarded.
That principle applies to body-weight data as well. An Apple Health export can be very large, but openGym is interested in the body-weight records rather than every health event in the archive. The importer reads the relevant values without treating the entire external export as the new profile. Workout history is also imported separately from routines. Bringing in what someone did does not automatically create or alter the weekly plan that will govern future sessions. The distinction protects both meanings: an old workout is evidence about the past, while a routine is intent for the future.
Plan sharing is a different operation. A plan file carries routines, weekly scheduling, and the custom-exercise metadata those routines need. It does not carry private workout history, weigh-ins, or binary media. The recipient can merge the shared routines into their own profile, with fresh identities so the imported plan does not overwrite an existing routine with the same apparent name. Unit conversion can happen as part of that exchange. The result is reusable intent, not a transfer of the sender’s personal training record.
A full backup has a different authority again. It is intended to move or restore the profile as a whole, and the documentation distinguishes ordinary JSON backup from a media-inclusive archive. Importing a full backup can replace the current state, which is exactly why it should not be used casually when the goal is merely to borrow a routine. A plan share is additive and scoped. A full restore is broad and potentially destructive. Confusing them turns a convenient recovery mechanism into an accidental overwrite.