Transferring or Deferring a Race Registration
A transfer moves a runner's existing registration to a different person; a deferral moves it to a future edition of the event, for the same runner. Having a clear, published policy for both, even a restrictive one, causes far fewer problems than handling each request case by case.
Why this needs a written policy
Runners will ask about transfers and deferrals regardless of whether you have a policy for them, usually close to race day when an injury, travel conflict, or schedule change comes up. Without a stated policy, every request turns into a negotiation, and inconsistent decisions across similar requests tend to generate fairness complaints. A clearly stated policy, even a firm 'no transfers, no deferrals', is more defensible than silence followed by an improvised answer.
Deciding what to allow
| Question | What to decide |
|---|---|
| Are transfers allowed at all? | Yes, no, or only up to a cutoff date before the event |
| Is there a transfer fee? | Free, a flat admin fee, or a percentage of the registration price |
| Are deferrals allowed? | To the next edition only, within a set window, or not at all |
| Who handles the logistics? | Self-service through the runner's account, or handled manually by your team |
Common approaches organizers take
- Transfers allowed up to a set cutoff, often one to two weeks before the event, with a small admin fee to cover reprocessing.
- Deferrals allowed to the next edition only, sometimes as a partial credit rather than a full carryover, to account for costs already committed on the current edition.
- No refunds under either option, since a transfer or deferral is typically offered as an alternative to a refund, not in addition to one.
- A firm cutoff after which neither is possible, since bibs, timing and kit often need to be finalised close to race day.
Why organizers land in different places on this
The right policy depends partly on how far in advance costs are locked in. An event with significant upfront costs per runner, printed bibs, a sit-down finisher meal, individually ordered kit, has less room for free transfers close to race day than one where marginal cost per runner is lower. Neither approach is wrong; the point is to base the policy on your actual cost structure rather than copying another event's terms without thinking through whether they fit yours.
It's also worth considering your event's stage. A first edition with no track record of demand might lean more permissive to build goodwill and reduce the risk of a bad first experience turning someone off future editions. A well-established event with reliable sell-out demand has less need to bend on this, since a runner who can't make it can usually resell interest in the category more easily than in a newer event still building its base.
Communicating the policy clearly
Publish the policy on the event page and in the registration confirmation, not buried in general terms runners are unlikely to read closely. State it before runners ask, since requests spike close to race day exactly when circumstances change. This works best alongside the rest of your pre-launch setup, covered in race registration checklist, and ties into the broader habit of communicating updates to registered runners clearly and early rather than reactively.
Handling requests that don't fit the policy
Occasionally a request falls outside what your policy covers, a medical emergency close to race day, for instance. Decide in advance whether you'll allow limited exceptions and who has the authority to grant them, rather than deciding under pressure in the moment. Route unusual cases through a single contact point rather than letting them arrive through multiple channels.
Keep a simple written record of any exception granted and why, even informally. This matters more than it sounds: the second time a similar request comes in, you'll want to know what you decided before and be consistent about it, rather than relying on memory or making a different call under different pressure.
What a clear policy actually protects
A written transfer and deferral policy protects your team's time as much as it protects runners. Every request handled against a clear, pre-decided standard takes a fraction of the time of one negotiated from scratch, and it removes the awkwardness of having to make a judgment call on the spot for someone who's upset about a missed race. That time saved compounds across an event with hundreds or thousands of runners, even if any single request seems minor on its own.
List your event and configure transfer, deferral and refund policies from the start.
List your eventThe organizers we see get the fewest complicated late requests, based on what comes up on the platform, tend to be the ones who published a transfer and deferral policy on the event page from day one rather than deciding case by case once requests started arriving. My honest read is that a clearly stated 'no' causes less friction than an unstated maybe, since runners at least know what to plan around.
Frequently asked questions
Should I allow bib transfers at all?
It's a judgment call, but allowing transfers up to a reasonable cutoff, even with a fee, tends to reduce frustration compared to a flat no, since runners view it as a fairer alternative to losing their registration entirely to injury or a schedule conflict.
What's a reasonable transfer or deferral cutoff?
Many organizers set it one to two weeks before the event, giving enough time to update bibs, timing records and any printed materials before logistics are finalised.
Should transfers and deferrals be free?
A small admin fee is common and reasonable, since reprocessing a registration does take staff time, but keep it modest and clearly stated rather than treating it as a revenue opportunity.
Do I need to offer both transfers and deferrals?
No, some organizers only offer one or the other, or neither. What matters more than which options you choose is stating the policy clearly and applying it consistently to every request.