How to Migrate from RideWithGPS Without Losing Routes

How to migrate from RideWithGPS without losing routes

Moving route platforms sounds simple until the first imported file sends you down the wrong road, drops a cue, strips a waypoint, or quietly changes the elevation profile you built a pacing plan around.

That is the real risk when you migrate from RideWithGPS. The issue is rarely whether you can export a file. The issue is whether the route still does the job it was built to do after it lands somewhere else.

A cycling route is not just a line on a map. For a serious rider, it can be a pacing framework, a fueling plan, a climbing benchmark, a group ride agreement, or a race recon file. If you treat migration as a bulk download and upload job, you may preserve the visible shape while losing the details that made the route useful.

The right workflow is simple: audit first, export deliberately, verify after import, then field test anything that matters outdoors.

Decide what deserves to migrate

Before exporting anything, identify which routes are still useful.

Most route libraries contain old experiments, duplicate loops, abandoned group ride options and slightly modified copies of the same course. Moving all of that clutter into a new platform is not thorough. It is how a route library becomes less trustworthy.

Start by sorting routes into practical categories:

• Routes you actively ride
• Routes tied to training sessions
• Race or event recon routes
• Group ride routes
• Travel routes you may use again
• Archive routes worth saving offline
• Routes to delete rather than migrate

Be ruthless with stale routes. If a file was built for an old trip, an event you will not repeat, or a test loop you no longer use, exporting it into a new system only creates future ambiguity. A serious rider does not need a larger library. They need a cleaner one.

The routes that deserve the most scrutiny are the ones where failure has consequences: race recon, remote gravel, travel days, group rides and structured training routes. A wrong turn on a casual recovery spin is annoying. A wrong turn on an unfamiliar gravel route, or a missing cue while leading a group, is a different category of problem.

Audit privacy before export

Privacy settings are easy to overlook because they feel separate from the route file. In practice, they are part of the migration risk.

Some routes reveal home starts, workplace locations, regular training roads or sensitive group meeting points. Do not assume privacy settings will transfer cleanly into the new platform. Even when an imported route receives a default visibility setting, that default may not match the original.

For any sensitive route, decide before export whether to:

• Edit the start and finish
• Keep the route private after import
• Save the file offline instead of uploading it
• Delete the route if it no longer has value

Collections deserve the same audit. A folder for winter endurance routes says something different than a folder for race openers or gravel options. But collections and folders are not always portable in a useful way, so expect to rebuild structure after import. That is not wasted work. It is a chance to rebuild around how you ride now.

Export a single route from RideWithGPS

For an individual route, use a controlled export instead of grabbing the first file type available.

A practical single-route workflow:

1. Log in to RideWithGPS.
2. Open your route library and select the route you want to move.
3. Open the route page, then find the export option from the route menu or export panel.
4. Export the route in the format that matches its use: GPX, TCX or FIT.
5. Save the file with a useful name that includes the route purpose, not just the platform default.
6. Import that file into the destination platform.
7. Compare the imported route against the original before moving on to the next important route.

For simple routes, one export may be enough. For any route with cues, waypoints, custom notes, off-road connectors, event instructions or device-specific behavior, export more than one format and test the imports side by side.

Handle library-scale exports carefully

A large migration is where riders get into trouble. Bulk export feels efficient, but it can hide failure because you stop looking at individual routes.

If RideWithGPS offers an account-level export or library export in your account, treat it as an archive first, not as proof that every route is ready to ride. Export availability, file structure and what gets preserved can depend on the tools available in your account and the receiving platform. Do not assume a bulk export will preserve collections, privacy settings, cues, waypoints or route notes in a ride-ready way.

The safer workflow is:

1. Create an offline archive of whatever RideWithGPS allows you to export.
2. Pick a small sample of important route types: simple road, cue-heavy road, gravel, group ride, training loop and race recon.
3. Import those sample routes into the new platform.
4. Check what survived and what failed.
5. Only then move the rest of the library.

If the destination platform imports a bulk file pile without collections, rebuild the organization manually. If a bulk export strips essential route intelligence, use it as a backup archive and re-export the critical routes individually in the format that behaves best.

Choose GPX, TCX or FIT by route job

The format choice should not be treated as a preference. It is a risk decision.

GPX is the broadest compatibility option. Use it when the primary need is to preserve the route line across mapping tools. It is often the right starting point for simple road loops, general endurance routes and archive copies. The warning sign is obvious: if cues, waypoints or custom route intelligence are missing after GPX import, GPX is not enough for that route.

TCX deserves priority when cues and course points matter. If you built the route with turn instructions, regroup points, control locations, landmarks or notes that affect execution, test TCX early. After import, inspect whether course points are retained, named correctly and placed where they belong. If TCX keeps the cue logic while GPX only keeps the line, TCX is the better operational file.

FIT is more device-oriented. Use it when the main goal is to get a course onto a head unit with minimal extra interpretation. The question is not only whether the platform accepts the FIT file. The question is how the device behaves: does it show the course cleanly, prompt at the right moments, display waypoints usefully and load the expected version?

The practical conclusion: do not pick one universal format for the whole library. GPX is fine for low-consequence routes. TCX should be tested for cue-heavy routes. FIT should be tested when the device workflow is the thing you are trying to preserve.

What to inspect after each import

An imported route becomes untrustworthy when it looks correct at a glance but fails the job it was meant to do. That is why the first verification pass should focus on function, not aesthetics.

Check these items after each import:

• Start and finish location
• Route direction
• Turn cues
• Course points
• Waypoints and waypoint names
• Route notes or description
• Off-road, path and connector sections
• Complex junctions
• Surface labels where they affect tire choice or pacing
• Elevation profile shape
• Segments used for efforts, testing or race simulation

Format-specific failure signals matter:

• GPX is unsuitable if the route line imports but the cues or essential waypoints disappear.
• TCX is unsuitable if course points import in the wrong places, duplicate badly, or fail to appear on the target device.
• FIT is unsuitable if the device loads the route but handles prompts, direction, waypoints or sync behavior unpredictably.

A clean-looking file that cannot guide the ride is not a successful migration.

Verification checklist before a real migration session

Use this as a quick decision table before exporting the routes you actually depend on.

Route type	Acceptable tolerance	Must-check items	Recommended export format
Simple endurance loop	Small line or elevation differences are usually acceptable if the route remains safe and recognizable	Start, finish, direction, major turns, elevation profile shape	GPX first, TCX if cues matter
Structured training route	Low tolerance where terrain controls the session	Effort sections, interruptions, climb or flat-road continuity, cue timing	TCX first, GPX backup
Race or event recon	Very low tolerance because planning decisions depend on the file	Official versus adapted status, course points, surface, technical sectors, device behavior	TCX and FIT tested side by side
Group ride route	Very low tolerance because errors affect the whole group	Cues, regroup points, risky junctions, stops, route direction	TCX first, FIT if used on head units
Gravel or remote route	Very low tolerance where reroutes can create safety or logistics problems	Surface, connectors, waypoints, water or stop notes, device prompts	TCX plus GPX backup
Archive-only route	High tolerance if it is not being used outdoors	File opens, name is clear, route is stored offline	GPX

The key is to separate route importance from route quantity. A library with many unchecked imports is weaker than a smaller library where the critical routes have been verified.

Preserve cues, waypoints and route notes

Cue sheets are easy to underestimate until they disappear.

If you ride alone on unfamiliar roads, cues reduce cognitive load. If you lead group rides, cues help keep the route predictable. If you are using a course for training, notes can remind you where to start an interval, where to recover, or where a technical section begins.

During migration, check whether the new platform preserved the original cue structure or generated its own. Regenerated cues can be helpful, but they can also erase the reason the route was built a certain way. A generic turn instruction is not the same as a note for a confusing junction, rough sector, regroup point or planned stop.

For critical routes, copy important notes into a separate document during the migration process. If there are essential waypoints, record their names and purpose. If the new platform drops them, you can rebuild them manually instead of trying to remember why they were there.

Check elevation, surface and distance after import

Once a route is imported, compare it against the original before trusting it.

Distance can shift if the new platform snaps the route to roads differently, simplifies the track, or recalculates sections. Elevation can shift because platforms use different elevation models and smoothing methods. Surface data can change because each platform classifies roads and paths differently.

For endurance athletes, these changes are not cosmetic. They affect planning.

A route with a different elevation profile can change how you pace a long ride or climbing session. A route with altered surface classification can turn a steady endurance day into a higher-fatigue ride. A small reroute onto a busier road can make a group ride less safe. If you are using a route to anchor an interval workout, even a subtle change in where the uninterrupted road begins can undermine the session.

If a route is tied to performance work, be strict. A route used for general aerobic volume has more tolerance for imperfection. A route used for threshold work, race prep or repeatable field testing does not. If you are building workouts around power targets, the route should support the physiological goal. A steady climb, uninterrupted flat road, or controlled loop matters because it changes how cleanly you can execute the effort. For background on how those targets are anchored, see the guide to functional threshold power.

Rebuild collections around how you ride now

After the files are imported, rebuild your library around use cases.

This is where many riders stop too early. They get the routes into the new platform, then leave them as a flat pile of files. That works briefly, then fails when you are trying to find the right route before a ride.

Useful collections should help you make decisions under time pressure:

• Endurance routes
• Short weekday routes
• Long weekend routes
• Climbing routes
• Structured training routes
• Race recon
• Group rides
• Gravel or mixed-surface routes
• Travel routes
• Routes to test before use
• Archived routes

Separate confidence level from route type. A beautiful imported route that has not been checked should not sit beside a proven route you trust for a group ride. Create a temporary review collection so imported routes have to earn their way into the main library.

For racing and events, document route status. If a route came from an event file, note whether it is official, provisional, self-built or adapted. That distinction matters when you are planning equipment, pacing and logistics.

For group rides, use only routes that have been checked and ideally ridden recently. A group route carries a higher burden because the cost of a routing mistake is multiplied across everyone on the ride.

Test key routes on the device you will use

A route can pass every desktop check and still behave poorly outside.

The head unit may interpret cues differently. A path may be closed. A junction may be confusing at speed. The route may load correctly but fail to give timely prompts. The new platform may sync one version while your device holds another.

Before using a migrated route for an important ride, test the full workflow:

1. Import the route into the new platform.
2. Confirm it visually in the platform.
3. Sync or transfer it to your device.
4. Open it on the device before leaving.
5. Check the start location and direction.
6. Confirm cues, waypoints and course behavior.
7. Ride a representative section if the route is important.

Pay particular attention to race recon, travel days, remote gravel rides, group rides and structured training. Those are the situations where route failure costs the most.

If a route is mission-critical, keep a backup file offline. Do not make the new platform the only place that route exists until you have used it successfully. A simple folder of exported route files gives you a fallback if sync fails, a platform changes behavior, or a device update disrupts your usual process.

A clean migration beats a fast migration

The temptation is to bulk export everything, bulk import everything, and declare the job done. That is fast, but it is not the same as a reliable migration.

To migrate from RideWithGPS without losing routes, protect the route’s function first. Audit what matters. Delete what no longer earns its place. Export important routes deliberately. Test GPX, TCX and FIT where route behavior matters. Recheck cues, distance, elevation, surface and device behavior after import. Rebuild collections around training, racing and group ride use.

The point is not to create a perfect archive. The point is to make sure that when you open a route before a ride, you know what it is, why it exists, and whether you can trust it.