How to Migrate from TrainingPeaks Without Losing History

The goal is not just to move files

When athletes decide to migrate from TrainingPeaks, the obvious task is exporting workouts and importing them somewhere else. That is only the surface layer.

The real goal is preserving decision-making context. Your cycling training history is not just a stack of ride files. It is the record of what you were trying to improve, how your body responded, when fatigue accumulated, where consistency broke down, and which interventions worked.

If you move training data badly, you may still have the rides, but lose the story. That matters because good endurance training depends on pattern recognition. A coach, athlete, or algorithm can make better calls when past load, subjective feedback, power files, goals, interruptions, and plan structure all remain legible.

The cleanest migration is not the fastest one. It is the one that preserves enough raw data and enough context that your next platform can still answer the questions that matter: what training did you actually do, what did it cost, what adaptation did it produce, and what should change next.

What data you should preserve before switching platforms

Before you export TrainingPeaks workouts, separate your data into three categories: irreplaceable, useful, and reconstructable.

Irreplaceable data

This is the material you cannot recreate accurately later:

• Completed activities with original power, heart rate, cadence, GPS, and timing data
• Athlete comments and coach comments
• Subjective metrics such as perceived exertion, mood, sleep notes, soreness, and illness notes
• Workout titles and descriptions that explain the intent
• Race notes and post-event reflections
• Testing notes and benchmark efforts
• Goal events and training phase context

The activity file tells you what happened. The comments often tell you why it happened. If a threshold session collapsed because of travel, poor sleep, or accumulating fatigue, that explanation is more valuable than the failed intervals themselves.

Useful data

This helps rebuild continuity but can sometimes be approximated:

• Planned workouts
• Completed versus planned comparisons
• Weekly structure
• Training blocks and recovery weeks
• Coach attachments, documents, or linked resources
• Nutrition notes
• Strength, mobility, and cross-training entries

Planned workouts are especially important if you want to understand intent. A completed endurance ride looks different when it was supposed to be a recovery spin, a long aerobic ride, or a substitute for a missed interval day.

Reconstructable data

Some platform-specific outputs may not transfer cleanly, but can be rebuilt if the underlying files are intact:

• Fitness, fatigue, and form charts
• Personal best summaries
• Power curve views
• Zone distributions
• Calendar compliance metrics
• Load models based on platform-specific assumptions

Do not panic if these do not transfer perfectly. If your ride files and thresholds are preserved, a new platform can usually recalculate its own version. The key is knowing that the numbers may not match exactly because each platform can define and display load differently.

If you need to re-establish baseline numbers before rebuilding plans, tools like the /tools/ftp-estimator can help sanity-check current training zones against recent performance.

Workouts, plans, activities, and comments: what exports cleanly

A migration usually works best when you treat each data type separately rather than expecting one export to carry everything.

Completed activities

Completed ride files are the foundation. Prioritize original activity files whenever possible because they carry the richest record of the session. For cyclists, the most important channels are power, heart rate, cadence, GPS, elevation, timestamps, pauses, and lap markers.

This is where moving training data can go wrong in subtle ways. A file can import successfully but still lose something important. For example, laps may disappear, GPS may be simplified, or power may be treated differently depending on the source file and destination platform.

After import, do not just check that the ride appears on the calendar. Open several key rides and confirm that the workout trace still behaves correctly.

Planned workouts

Planned workouts are more fragile because platforms structure them differently. A workout builder session may not export with every step, target, note, or progression intact. Even when the broad structure transfers, small details can change.

That matters because a workout is a prescription, not just a duration. A session built around controlled sweet spot work is not the same as a free-form ride with similar total load. If the target ranges, interval order, or recovery instructions vanish, the future training value drops.

For near-term training, assume you may need to manually rebuild key workouts in the new system.

Training plans

Plans are often less portable than activities. The workouts may move, but the logic of the plan may not. Blocks, progressions, rest timing, annotations, and coach rationale can be embedded in a way that does not survive a simple export.

If you are following a structured plan, capture the next training block before switching. Screenshots are not elegant, but they can preserve context when export options are limited. A cleaner approach is to document the upcoming structure in plain language: the goal of the block, the key workouts, the expected progression, and the recovery pattern.

Comments and notes

Comments are the most underrated part of a migration. They are also among the easiest to lose.

For serious cyclists, comments often explain the gap between model and reality. They tell you when a workout was completed indoors because of weather, when power was suppressed by fatigue, when heart rate was unusually high, or when a successful session came after extra recovery.

If comments do not export cleanly, preserve them manually for key periods: testing blocks, race builds, illness periods, injury interruptions, and successful performance peaks. You do not need every throwaway note, but you do need the annotations that change interpretation.

Common gaps when moving years of training history

The longer your training history, the more likely small inconsistencies will appear. That does not mean the migration failed. It means you need to identify which gaps matter.

Platform-specific metrics may not match

Fitness, fatigue, and form are models, not physical objects. A new platform may calculate training load differently or apply thresholds in a different way. Even if the same rides import correctly, the chart may not look identical.

This is not necessarily a problem. In fact, it can be useful. The trap is trying to force the new platform to recreate the old one perfectly. The better approach is to understand the new model, make sure your thresholds and zones are set correctly, and then let future trends become the reference.

If you need a refresher on threshold-based structure, the /glossary/ftp page is a useful anchor.

Indoor and outdoor files can split differently

Indoor files, head-unit files, smart trainer uploads, and synced app activities can create duplicates or partial versions of the same workout. One file might have better power data. Another might have better workout-step compliance. Another might carry the title and notes.

During migration, duplicates are not just clutter. They can distort load, volume, and trend analysis. If your new platform imports overlapping versions of the same session, decide which file is the source of truth and delete or archive the rest.

Old threshold settings may be missing

Historical training load is only as good as the threshold context applied to it. If your FTP changed over time but the new platform applies one current value across old rides, historical intensity can look wrong.

You may not need perfect historical thresholds for every period, but you should preserve known benchmark points: ramp tests, time trials, race-derived estimates, and coach-updated values. These let you interpret past blocks with more accuracy and prevent old training from being judged against the wrong fitness level.

Non-cycling work may be undercounted

Strength sessions, mobility, running, hiking, and other stressors often migrate less cleanly than rides. For a cyclist, that can create a false sense of freshness in the historical record.

If a period included meaningful non-bike stress, make sure the notes survive even if the workouts do not. This is especially important around injury rehab, general preparation, and race build phases where off-bike work can explain fatigue or adaptation.

How to keep context around fitness, fatigue, and goals

A good migration includes a narrative handover. Before leaving the old platform, write a short training memo for yourself or your coach.

Include:

• Current goal events and why they matter
• Current strengths and limitations
• Recent training focus
• Known fatigue signals
• Current threshold and zone assumptions
• Recent interruptions from illness, travel, injury, or life stress
• What has worked well in training
• What has failed repeatedly

This memo does something the export file cannot. It compresses the meaning of your recent training into a form that survives the platform change.

For example, two athletes can have similar recent ride histories, but very different next steps. One may need more aerobic durability. Another may need sharper race-specific intensity. One may be carrying fatigue. Another may be undertrained but fresh. The calendar alone will not always show that.

If you are moving to one of the many TrainingPeaks alternatives, do not evaluate it only by how the old files look on day one. Evaluate whether the platform helps you make better decisions from day two onward.

Checking imported rides for power, heart rate, and GPS errors

Once the import is complete, audit the data before trusting the charts.

Start with a small sample of important rides rather than scrolling the entire calendar. Pick recent rides, race files, benchmark efforts, indoor workouts, long endurance rides, and any sessions you know had unusual data.

For each file, check:

• Does duration match your memory of the session?
• Does moving time look reasonable?
• Is power present for the full ride?
• Are there obvious power spikes or dropouts?
• Is heart rate present and aligned with effort?
• Does cadence appear where expected?
• Does GPS mapping look intact for outdoor rides?
• Are laps or intervals still visible?
• Did the workout title and notes transfer?
• Is the ride duplicated anywhere else?

Power errors matter most because they feed training load, intensity analysis, and performance modeling. A single bad spike can distort best-effort curves. Missing power can make a hard ride look easy. Duplicates can make a normal week look like overload.

Heart rate errors are different. They may not always dominate load calculations, but they are critical for understanding durability, heat response, fatigue, decoupling, and aerobic control. If heart rate is missing from important aerobic rides, the ride still has value, but part of the physiological picture is gone.

GPS errors are usually less damaging for training load, but they matter for route context, climbing analysis, and race review. If your outdoor files are central to how you review terrain and pacing, confirm they survived intact.

Rebuilding future plans after the migration

Do not migrate in the middle of a delicate training block unless you have to. The safest time to switch is when the next phase can be rebuilt deliberately.

Start by separating future planning into three layers.

The goal layer

Define what the next block is meant to accomplish. This should be specific enough to guide workout selection: raising threshold, rebuilding consistency, improving endurance durability, sharpening repeatability, preparing for a target event, or absorbing a previous load phase.

The structure layer

Decide how training stress will be distributed across the week. Keep the architecture simple at first. A migration is not the moment to add complexity. Preserve the sessions that matter most, then let the new platform support execution and review.

The workout layer

Rebuild key workouts manually if export quality is uncertain. Check target zones, interval durations, recovery instructions, and notes. Then sync a test workout to your head unit or training app before relying on it for an important session.

This is where many athletes make the wrong tradeoff. They spend time trying to rescue every old planned workout while neglecting the next few weeks of actual training. Historical data matters, but the immediate plan is what determines whether the migration disrupts fitness.

A pre-switch checklist for serious cyclists

Use this before you commit to the move:

• Export completed activity files, prioritizing original files where possible
• Preserve comments and notes from key training periods
• Save current and historical threshold information where available
• Document current goals, fatigue state, and training focus
• Capture the next training block before cancelling access
• Identify planned workouts that must be rebuilt manually
• Check whether strength, mobility, and cross-training notes are preserved
• Import a small test batch before moving everything
• Audit imported rides for power, heart rate, GPS, laps, titles, and duplicates
• Compare several key workouts between old and new platforms
• Rebuild zones and athlete settings in the new platform
• Sync a test workout to your device before the first important session
• Keep the old account accessible until you have verified the migration

The smart migration preserves interpretation

To migrate from TrainingPeaks well, think like an analyst rather than an archivist.

An archivist wants every file moved. An analyst wants the files, the assumptions, and the context that make the files useful.

Completed rides are the base layer. Plans explain intent. Comments explain exceptions. Threshold history explains intensity. Goals explain why the training was structured the way it was. Without those pieces, a new platform may show a complete calendar that is less informative than it looks.

The best migration leaves you with continuity. You should be able to open the new platform and understand where fitness has come from, what fatigue may still be present, what the next block is trying to achieve, and which data you can trust.

That is the standard. Not just a successful import, but a training history that still helps you make better decisions.