How to Switch NDIS Software Without Breaking Your Operation

Most NDIS software switches don't fail. They run 3× over their planned timeline, blow a month of operations team capacity, and end with the team quietly using both systems in parallel for 6 months because nobody trusts the migration finished cleanly.

The reasons are predictable. Providers underestimate three things during evaluation:

1. Claim-cycle continuity. The fortnight you switch is still a fortnight that needs to be invoiced. Half-migrated rosters, half-imported participants, and a partially-configured PACE export means missed claims — exactly the revenue leak you were trying to fix.
2. Audit-trail import. Your audit pack needs to work across a 12-month window. Most providers forget this until the auditor asks for January and the new system only has shifts from April onwards.
3. Parallel-run cost. Running the old system AND the new one for "a few weeks" routinely turns into 6 months. Two licences, two sets of logins, two truths about which shifts have been claimed. The cost is real even if it doesn't show up on the budget line.

This post is about how to plan a switch that handles all three. The framework works whether you're moving from a spreadsheet, ShiftCare, SupportAbility, Lumary, or any other NDIS tool.

The 4 components of a clean switch

Every NDIS software migration has the same four phases. Underweight any one and the timeline explodes.

1. Data migration

What needs to come across:

• Participant master list. Names, NDIS numbers, plan dates, plan management type (NDIA-managed / plan-managed / self-managed), funding category breakdowns, goals, support plan PDFs, Service Agreements (current version + archived previous versions).
• Worker master list. Names, contact details, NDIS Worker Screening Check dates, qualifications + expiry dates, NDIS Worker Orientation Module completion [NDIS-CHECK: confirm at ndiscommission.gov.au/workers/training/worker-orientation-module], First Aid + manual handling certificates.
• Service item catalogue. Mapped to the current Pricing Arrangements PDF on ndis.gov.au, not your old system's stale internal codes [NDIS-CHECK: codes update annually 1 July; verify current version before mapping].
• Historical shifts. At least 12 months back, ideally 18 months for renewal-audit cycles. Includes shift date, worker, participant, support item, hours, claim status (claimed / unclaimed / paid / rejected), invoice reference.
• Progress notes. The shifts above are useless to an auditor without their associated same-day progress notes. Notes are the evidence — shifts are just the metadata.
• Incident register. Every incident from the last 12 months, with the full six-field structure (what happened / who was involved / what was investigated / what was found / what changed / date of closure).

The cost of skipping any of these: an audit pack that doesn't span the required window. The provider above 30 active participants will discover this on the auditor's first request.

2. Team training

Most vendors say "intuitive, no training required." That's marketing copy. The honest reality:

• Operations manager: 4–6 hours to learn the new rostering flow, claim batch process, and reporting
• Coordinators / case managers: 2–3 hours each on the new participant management interface
• Support workers: 30 minutes on the mobile app (clock-in, note submission, incident reporting)
• Bookkeeper / accounts: 2 hours on the invoice generation + PACE export flow
• Owner / director: 1 hour on the executive dashboards

That's typically 15–25 hours of distributed team training time for a 10-worker provider. For a 30-worker provider, it's 30–50 hours. None of this happens for free — it comes out of the operations team's existing capacity, and you should plan for the productivity dip during the training period.

A vendor that won't quote training time honestly is hiding something. Ask for it specifically.

3. Parallel run period

This is where most migrations go sideways. The temptation is to "run both systems for a month to be safe." In practice:

• The operations team double-enters every roster change
• The bookkeeper checks every invoice in both systems
• Workers get two notifications for every shift
• After 3 weeks everyone is exhausted and confused about which system is the source of truth

The honest answer: parallel run for 2 weeks, then cut over fully. Less than 2 weeks and you haven't tested the new system through a full claim cycle. More than 2 weeks and the team starts cutting corners on the new system because the old one is "still working."

What the 2 weeks should cover:

• Week 1: New system in shadow mode. Operations team uses old system for live work, but mirrors changes into the new system to validate workflows match expectations.
• Week 2: New system is primary. Old system stays read-only for reference. Any failure escalates to vendor support immediately, not "we'll work around it."

After Week 2: old system is archived (read-only access kept for 12 months for audit reference), new system is the source of truth. No more dual-entry.

4. Cutover plan

The cutover is the moment the new system becomes the source of truth. It has to land at a specific time, with everyone on the team aware, and a clear rollback plan if something breaks.

A clean cutover schedule:

The risk you can't insure against — claim continuity

The single biggest hidden cost of a botched switch: claims that should have been submitted slip past their submission window.

The NDIS has rules about claim timing [NDIS-CHECK: claim window rules are defined in the NDIS Pricing Arrangements + the Provider Payment Policy; confirm current claim window at ndis.gov.au/providers]. Miss the window and the claim is gone — you delivered the service, you just don't get paid for it.

The risk shape:

• Old system was submitting fortnightly
• Migration ate 2 weeks of focus
• Some shifts didn't get claimed in either system
• The provider doesn't notice until reconciliation 30 days later
• By then the submission window has closed on those shifts

How to prevent this:

• Run an explicit claim reconciliation between old and new system at end of Week 1, Week 2, Week 4 of the migration
• Track every shift that was in-flight across the cutover with a specific tag in the new system
• Don't let any shift sit "pending" longer than 7 days post-cutover — flag and resolve

What to ask any vendor before signing

These five questions filter out the vendors who haven't actually thought about migration:

1. "What's your data import format?" Honest answer: a specific CSV schema or SQL dump format. Vague answer: "we'll work with you." The vague answer means weeks of back-and-forth.

2. "Will my historical audit pack work after migration?" Honest answer: "yes, here's an example with sample data." Vague answer: "the audit pack works going forward." That means your last 12 months disappear from the audit trail.

3. "How long until our first claim batch goes out cleanly?" Honest answer: "2 weeks from contract sign, assuming clean data export from your current system." Vague answer: "depends on your operation." This is the vendor flagging that they don't know either.

4. "Who specifically will be on the migration call?" Honest answer: "[Named person], with [named backup], available [specific hours]." Vague answer: "our support team." Translation: your ticket joins a queue with everyone else's.

5. "What happens if we decide it's not working at 30 days?" Honest answer: "Full data export in [specific format], 30 days of read-only access while you switch, no exit fee." Vague answer: "we don't have churn, that won't happen." That's the vendor telling you they haven't thought about your interests.

A 4-week switching timeline (the honest version)

4 weeks calendar time, ~30 hours of distributed team effort, 1 weekend of cutover work. That's the actual cost — anyone quoting "1-week migration" is undercutting an estimate that won't hold.

What Tendaroo does about migration

We've written a separate honest comparison against ShiftCare, SupportAbility, and Lumary — including which migrations we've done, what they cost in time, and where we genuinely won't be the right fit.

If you're in the middle of evaluating and want a direct conversation about whether Tendaroo fits your specific operation: start a 30-day free trial — no credit card, no demo gate. We're founder-led right now, so the migration call is with someone who actually built the import flow, not a sales rep.

And if you want the operational reference doc for what your team should be doing during the switch: the NDIS Audit Preparation Checklist (PDF) covers the audit-trail-continuity requirements in depth — most providers find the audit-related sections become urgent precisely during a migration.