Event Information

With ChronoTrack Live Registration sunsetting in 2026, many timers are beginning to plan their transition to new platforms. In this webinar, we’ll walk through a streamlined solution that makes migrating events with past registration data to RunSignup fast and efficient—using RaceDay Scoring.

You’ll learn how RaceDay Scoring can easily pull in your past registration data and simplify much of the setup that would otherwise need to be recreated manually. We’ll cover step-by-step how the migration process works, best practices for ensuring accurate and complete data transfer, and tips for preparing your events on RunSignup for a smooth registration and scoring experience.

This session is designed specifically for timers who want an easy, reliable workflow for moving their events off other registration platforms and onto RunSignup while saving time and reducing errors.

Join us to see how RaceDay Scoring can make your transition seamless.

View Slides

Summary of Webinar 

What this webinar covered (agenda)

1. What backfilling is

2. When to use it / when not to use RDS for it

3. How to quickly create past events in RunSignup

4. How to use RDS to import past participants into those past events

5. Brief note on importing past results (optional follow-on)

6. Q&A + resources (Timer Summit, certifications, support channels)

Core concept: What “backfilling” means

Backfilling = importing past participants into RunSignup from another system (here: ChronoTrack Live registration exports). The value is mostly for race organizers, not necessarily the timer directly.

Why organizers want backfilled participants

• Email marketing (Email V2): create dynamic lists like
  “Registered in past 2–3 years but not registered this year” → send a re-engagement email.

• Year-over-year tracking: compare registration counts and trends vs past years.

When NOT to use RDS for backfilling

If you need to preserve financial/fundraising data details, RDS backfill is not the right method:

• Fundraiser info

• Donation history

• Add-ons / store item details

• Anything where financial tracking needs to be maintained historically

In those cases, use a platform-side approach (paper import / RunSignup account manager / RunSignup support).

Key RunSignup model reminder (important for CT Live users)

• In RunSignup: Race is the evergreen container; Events are year-specific.

• (This is opposite terminology compared to CT Live, as noted in the webinar.)

Participants must be attached to a specific year’s event to exist in RunSignup’s data model.

Step 1: Create past-year events in RunSignup (fast method)

Path described:

• Results → Edit Results → Upload New Results (or search “Edit Results” from the dashboard search)

From Upload New Results, use the Event dropdown:

• Click “Create the event here” to quickly create past-year events.

Fast option: “Copy current events to this year”

• Choose the year you want to create.

• Click Copy current events to this year.

Critical warning: do one year at a time.
If you try to do multiple years at once, you can end up with events attributed incorrectly to the same year, which creates problems later when importing participants year-by-year (and especially when importing the same participant across multiple years).

After creation:

• You can delete unwanted events (X) and add additional events as needed.

• Update event date (important for age calculations). Start time is less important for backfill.

Step 2: Import the race into RaceDay Scoring (must be “already on RunSignup”)

In RDS:

• Manage Races → Import a race already on RunSignup

Do not use “Create a new race” (it won’t connect to the RunSignup race you’re backfilling).

Date range gotcha

The default search range may be set to a future year—adjust the date range so the past event years appear. Verify you’re selecting the correct race/year by checking the date column.

Step 3: Establish bidirectional sync in RDS (required)

In RDS, go to Sync Settings (tab with two arrows):

• Save Sync Settings to establish bidirectional sync between RunSignup ↔ RDS for that event year.

Why this matters:

• Participants imported into RDS will be pushed to RunSignup via API.

• RunSignup custom questions will sync down once the connection is established.

  • You may need to leave/return to the tab or use Force Sync to see them.

Custom Questions vs Custom Fields (important distinction)

• Custom Questions = from RunSignup registration; they sync.

• Custom Fields = local to RDS; do not sync.

If a question existed in past years but not current year, and you want to preserve that historical data:

• Add it as a custom question and mark it Internal (so it doesn’t appear in current-year registration flow).

Step 4: Prepare the past participant data (CSV + required fields)

Data typically comes from CT Live as a spreadsheet export.

Requirements:

• Must be CSV

• Must include (and be mapped to):

  • First name

  • Last name

  • Registration event (column can be named differently, but must be mapped)

Other fields are optional, but helpful—with caveats:

Registration date

If the organizer wants to analyze registration trends year-over-year:

• Import registration date (must be a simple date format: month/day/year—not timestamps/timezones)

Giveaways caveat

Giveaway values come from the current registration year’s setup, so importing historical giveaway options can cause mismatches (e.g., unisex sizes in past years vs gendered sizes now). Consider skipping those fields unless you really need them.

Step 5: Import in RDS + map values (including event name mapping)

In RDS:

• Participants & Teams → Import

Common workflow:

1. Import CSV

2. Fix errors listed (RDS will show errors + row numbers)

3. Map fields

4. Handle “value mapping” when incoming values don’t match RunSignup values exactly (e.g., event names)

Example mentioned: incoming “10K” might need to map to a RunSignup event name like “Summer 10K”.

Don’t map problematic columns if you don’t need them

If you have a column like Corrals in old data but corrals don’t exist in current setup:

• Either map that column to blank during import, or

• Create an Internal custom question to store historical values.

Common errors + troubleshooting tips

• Age and DOB mismatch

  • First check: are you importing into the correct year?

  • If correct but conflicts remain: choose to import either DOB or Age, not both.

• Zip codes don’t match formatting

  • Annoying but often worth cleaning (especially with newer targeted list features like location-based marketing).

  • If it’s not worth it, remove that field—but note the tradeoff.

• Phone number format issues

  • If you don’t need it: map to blank or delete before import.

• Corral/giveaway values don’t exist

  • If not needed: map to blank.

  • If needed: create matching Internal custom questions.

• Registration date includes timestamps

  • Reformat to date-only (MM/DD/YYYY).

Repeat per year

Once one year is imported successfully:

• Repeat the same process for other years (import a different year’s CSV).

Optional follow-on: Import past results too

They briefly recommended (especially in the off-season):

• Use this as a chance to practice RDS by rescoring older events (ChronoTrack stores reads well).

• Benefit: once set up, you can Renew year-over-year so future scoring setup is faster.

Also noted: having results centralized helps with future “chatbot / conversational results lookup” initiatives (mentioned as something they’re working toward).