What this guide answers
- Why will nobody give us a straight number of weeks?
Because the honest answer depends on your content volume, whether a usable export exists, and how many evenings your committee can actually give it — none of which the vendor knows.
- What is the single biggest factor?
Whether your current platform gives you a clean member export.
- Can we switch mid-season?
You can, but it costs you. Registration periods, finals and payment runs all interrupt the work and raise the price of any mistake.
- Do we have to move everything at once?
No. The site, the roster and the payments can go across in stages, and staging them is often what makes a migration fit around volunteer availability.
- How long before members are actually using the new system?
That runs on the member clock and cannot be compressed, only started earlier.
New Zealand edition. This guide is written for volunteer-run clubs in New Zealand. Where rules differ — grants, tax, incorporation, safeguarding — follow the New Zealand-specific pointers below or check with your national body.
It is the question that ends most club software conversations, and it is almost always asked with a wince: how long is this actually going to take?
The wince is earned. Somebody on the committee has done one of these before, or knows someone who has, and remembers a project that started confidently in the off-season and was still half-finished when registrations opened.
We are not going to give you a number, and you should be suspicious of anyone who does. Not because it is unknowable, but because the honest answer depends almost entirely on things that are true about your club rather than things that are true about the software — and a vendor quoting an average is describing their fastest customer, not yours.
What this guide gives you instead is the set of factors that actually decide it, and a way to estimate your own before you commit to a date in front of the committee.
Why an average would mislead you
Two clubs of the same size can take wildly different amounts of time for reasons that have nothing to do with the platform they are moving to.
One has a website of a dozen pages, a current member spreadsheet the registrar maintains anyway, a domain in the club's own account, and a secretary who can make a decision without convening anybody. The other has fifteen years of news posts, a member list that exists in three places that disagree, a domain registered by a committee member who has since moved away, and a constitution requiring the full committee to approve anything that costs money.
Same sport, same number of members, same new platform. The work is not remotely comparable, and no average covers both. So rather than asking "how long does this take", ask "what is true about us that makes this slow or fast?"
The three clocks
It helps enormously to stop thinking of a migration as one duration. It is three, running at different speeds, and only the middle one usually matters.
The vendor clock. Account setup, importing a file, verifying a domain, issuing a certificate, processing a payment connection. This clock is mostly automatic and mostly waiting. It is fast and it is rarely your constraint — which is why the vendor's own estimate always sounds so encouraging.
The committee clock. Deciding what the new site says. Writing the pages. Agreeing the membership types. Checking the import. Signing off. This clock runs on volunteer evenings, and it is almost always the one that determines your finish date. It does not speed up when the software gets better.
The member clock. Re-authorising payments, setting new logins, updating bookmarks. This one runs entirely on other people's time and cannot be compressed at all — only started earlier. Our guide to switching without losing your members covers why the payment half of it is unavoidable on any platform.
A committee that plans around the vendor clock will be late. A committee that plans around its own availability, and starts the member clock early, generally will not.
The five things that actually drive it
1. How much content you have
Not how many members — how many pages, posts, documents and photos somebody has to move and check. A club with a lean site of the pages people actually read is doing a fundamentally smaller job than a club with a deep news archive and a decade of attached PDFs.
The useful question is not "how much do we have" but "how much are we moving". Most of a long news archive does not need to travel. Move the pages that answer questions — how to join, where we play, fees, policies, contacts — plus the recent seasons, and keep the rest as an offline archive.
2. Whether a usable export exists, and what shape it is in
This is the single biggest swing factor, and you can settle it in an afternoon.
If your current platform gives you a clean member export with the fields you need, the roster part of the move is an import and a check. If it gives you nothing, or a file with names mashed into one column and no membership type, then somebody is doing data work by hand and the timeline changes character entirely. Request the export before you agree any dates, and look at the actual file rather than being told it exists. Moving club member data between systems covers what a good export looks like.
The same question applies to payment history, form definitions and email templates — none of which usually export well, and all of which take committee time to reconstruct.
3. How often your committee can actually sit down
Count this honestly. Not how many people are on the committee — how many evenings, between now and your deadline, will genuinely be spent on this by the two or three people who will really do it.
That number is your budget, and it is usually much smaller than it looked at the meeting where everyone volunteered. A club that can put two people on it for a couple of evenings a week is running a different project from one relying on a single monthly meeting.
4. How much you decide to change while you are in there
This is the hidden multiplier, and it catches almost everyone. A migration reopens every settled argument: what the membership types should be, whether the fee structure still makes sense, what the home page should say, whether the logo should be refreshed. Each of those is reasonable on its own, and together they turn a copy job into a redesign and a governance review.
The discipline that saves timelines: version one is a faithful copy. Improvements are a separate piece of work, after the switch, when the pressure is off. Write that down at the start and point at it whenever the conversation drifts.
5. The calendar you are stuck with
Your club's year does not care about your project plan. Registration periods, season start, finals, the annual general meeting and the grant reporting deadline are all fixed points that either block the work or must not collide with it.
Work backwards from those rather than forwards from today. The off-season, after your last significant payment run and well clear of the next registration day, is the window; everything else is a compromise.
Estimating your own
Half an hour with a notepad gives you a better answer than any published average.
- Count the pages you will actually move. Click through your site and list them. This number, more than any other, sizes the typing.
- Count your active payers. That is the size of the re-authorisation campaign, and it runs on the member clock.
- Count your forms, and the questions on each. Registration, nomination, incident, uniform orders.
- Count your integrations. Anything connected to your current system — accounting, email, a governing body feed, a booking tool — is a separate small project each.
- Get the export and open it. Ten minutes that can change your whole estimate.
- Name the two people doing the work, and ask them how many evenings they have.
Now express the estimate in the units the work is actually done in: committee evenings, not calendar weeks. Calendar weeks hide the fact that nothing happens in most of them. A plan that says "roughly this many evenings of work, and we can do two a week around training" is one the committee can hold itself to. A plan that says "six weeks" is a wish.
What runs in parallel, and what cannot
Much of a migration is stubbornly sequential, but three things can genuinely overlap and should:
- Building the new site while the old one stays live. Non-negotiable, and it removes almost all the risk. Nothing switches until the new one is finished.
- Announcing the change while you build. Start the member clock early. People need to have heard about it several times before they are asked to do anything.
- Chasing exports and domain ownership from day one. These are the two items with external waiting time, and both can quietly block everything else.
What cannot be parallelised is the checking. The import check, the payment test and the redirect map all depend on the thing before them being finished.
What blows a timeline out
In rough order of how often they do it:
- The domain turns out not to be owned by the club, and getting it back becomes its own project.
- No usable export exists, so member data is retyped or reconstructed.
- One person holds every login and is away, or has left.
- Content decisions get reopened after they were agreed.
- The move happens during registration or mid-season and has to pause repeatedly.
- Every step waits for a full committee meeting to approve it.
- The re-authorisation campaign starts after the switch rather than before it.
Notice that only one of those is technical.
What makes it much quicker
- One person with authority to make content decisions without a meeting.
- An agreement, in writing, that version one is a copy.
- The export requested and checked before anything else starts.
- The domain confirmed in a club-owned account early.
- Building alongside the old site so there is no pressure to go live half-ready.
- A trimmed scope: the pages people actually read, and the last season or two of news.
The parts you must not rush
Speed is a virtue everywhere in this project except four places. Compressing any of these is how a fast migration becomes an expensive one.
- Testing payments end to end, with a real card, including a refund.
- Checking the import — count the totals, then spot-check individual records against the old system, including an awkward family and a life member.
- Mapping redirects from every old address to the page that answers the same question.
- Confirming email still works after any DNS change.
Commit to milestones, not a date
The most useful thing you can take to your committee is not a finish date. It is a sequence with a clear gate on each step: exports in hand and checked; domain confirmed in a club account; new site built and tested; import checked; redirects mapped; announcement made; switch; re-authorisation campaign run; old platform cancelled last.
Each of those is either done or not done, and anyone can see which. A club working to that list finishes when it finishes, and finishes properly. A club working to a date announced at a meeting in March either rushes the checking or spends the season explaining a delay.
Doing it on ClubHelix
The clock we can shorten is the vendor one, and honestly, that was never the problem. Setting up an organisation is a form, an existing roster comes in by spreadsheet import with duplicate detection and a dry-run preview, pages are rebuilt in a drag-and-drop page editor rather than in code, custom domains connect with guided DNS steps and a certificate issued automatically, and members join and renew themselves through self-serve registration so the roster keeps itself current afterwards. Reports give you the numbers to check the import against.
What we cannot shorten is the committee clock or the member clock. Somebody who knows what your club's pages should say still has to say it, and your payers still have to authorise again. That is true wherever you go, and a timeline that does not account for both is not a timeline.
If the volunteer evenings genuinely are not there, our done-for-you service does the build and the migration for you. Otherwise start free, build alongside your current system, and switch when the checklist is finished rather than when the calendar says so.
Frequently asked questions
Why will nobody give us a straight number of weeks?
Because the honest answer depends on your content volume, whether a usable export exists, and how many evenings your committee can actually give it — none of which the vendor knows. An average would describe somebody else's club. Estimate in committee evenings using the inventory above instead.
What is the single biggest factor?
Whether your current platform gives you a clean member export. A good export turns the roster into an import and a check. No export turns it into manual data work, which changes the size of the whole project. Settle this before you agree any dates.
Can we switch mid-season?
You can, but it costs you. Registration periods, finals and payment runs all interrupt the work and raise the price of any mistake. The off-season, after your last significant payment run and well clear of the next registration day, is where this belongs.
Do we have to move everything at once?
No. The site, the roster and the payments can go across in stages, and staging them is often what makes a migration fit around volunteer availability. What cannot be staged is the checking that follows each step.
How long before members are actually using the new system?
That runs on the member clock and cannot be compressed, only started earlier. Announce well before the switch, make the first action a single tap, and expect to chase in waves. The clubs that finish this quickly are the ones that started telling people early, not the ones with faster software.
Is a done-for-you build faster than doing it ourselves?
It removes the committee clock, which is usually the constraint — so yes, in wall-clock terms. It does not remove the decisions: someone from the club still has to say what the pages should contain and check the member records. And it never removes the member clock.
