Moving audit scheduling data to a new system: what to migrate and how
Audit scheduling data migration for certification bodies: which records to move, how much history to keep, how to clean competence data and test go-live.
Audit scheduling data migration means moving clients, sites, audit programmes, due dates, auditor competence, availability and allocation history into a new scheduling system. Migrate at least one full certification cycle of past allocations so rotation and conflict checks work, clean competence records before loading them, and test the new system against a real planning period before switching off the old one.
Key takeaways
- Competence records and allocation history matter most, because rotation and impartiality checks depend on them.
- Keep at least one full three-year certification cycle of history for every active client.
- Clean data at the source system, then load it; fixing it after go-live costs far more.
- Test on a real planning period and compare the result with your manual plan before switching over.
What is audit scheduling data migration?
Audit scheduling data migration is the move of everything a planner needs to build a compliant plan from old tools into a new scheduling system. The old tools are often a certification platform plus several spreadsheets, calendars and a planner's memory. The new system can only apply rules that it has data for, so gaps in the migration become gaps in the plan.
Most bodies underestimate two things: how much history the rules need, and how much of the competence data lives outside any system. This guide covers what to move, how to clean it and how to test it. If you are moving from spreadsheets, our spreadsheet migration guide adds detail on file structures.
Which data should you migrate?
Group the data by the rule it supports. That makes it obvious which records are essential and which are nice to have.
| Data set | Rule it supports | Typical source |
|---|---|---|
| Clients, sites and addresses | Travel, multi-site sampling | Certification platform or CRM |
| Standards, scopes and IAF codes per client | Competence matching | Certification platform |
| Audit programme, audit time and due dates | Windows and capacity | Certification platform |
| Auditor competence by standard, code and role, with dates | Competence on the audit date | Spreadsheets, HR files |
| Accreditation body per standard | Accredited scope | Quality records |
| Past allocations per client | Rotation, repeat-visit limits | Old schedules, audit reports |
| Declared conflicts of interest | Impartiality | Declarations, HR files |
| Auditor availability, holidays and home base | Calendars and travel | HR system, Outlook |
| Future bookings already confirmed | Continuity | Current schedule |
See the competence matrix guide for a structure that software can read.
How much history do you need to migrate?
Rotation and conflict checks look backwards. If the new system does not know who audited a client in the last cycle, it cannot apply your rotation policy, and it may send the same auditor back again. At minimum, migrate past allocations for one full three-year certification cycle for every active client, with auditor, role and dates. Where your rotation rules look back further, migrate further.
For recertification planning, the system also needs each certificate's expiry date and the date of the last certification decision. Our article on recertification audit timing explains why these dates matter.
Where does audit scheduling data migration usually go wrong?
Before loading anything, map each data item against each source and mark whether it is complete. The pattern below is typical: the certification platform holds client data well, while competence and history are scattered.
| Certification platform | Planner spreadsheets | HR files | |
|---|---|---|---|
| Clients and sites | |||
| Due dates | |||
| Competence by code and role | |||
| Competence expiry dates | |||
| Past allocations | |||
| Conflicts of interest |
CompletePartialMissing
Competence is where problems hide. When a global assurance provider scheduled 305 largely integrated audits in an engine, it found 46 historical competence gaps in its records. Finding such gaps during migration is uncomfortable but useful: it is far better than an accreditation assessor finding them. Our article on planning spreadsheet risks lists other common errors.
What does a realistic migration timeline look like?
Timelines depend on the number of sources and the state of the data. The illustrative sequence below suits a body with one certification platform and several planning spreadsheets.
- Weeks 1 to 2Scope and mappingList sources, agree the system of record for each item, map fields
- Weeks 2 to 4Clean at sourceFix competence codes, fill expiry dates, merge duplicate clients
- Weeks 4 to 5Trial loadLoad a copy, run validation reports, fix rejects
- Weeks 5 to 7Parallel planningPlan a real period in both old and new, compare results
- Week 8Cut-overFreeze old tools, final load, switch integrations on
- After go-liveHypercareDaily checks on sync, exceptions and planner feedback
How do you test migrated scheduling data?
Test the data by using it. A plan built from migrated data exposes gaps faster than any field-by-field check.
- ✓Record counts match source for clients, sites, audits and auditors
- ✓Every audit has a window or due date and an audit time
- ✓Every auditor has competence with dates for each standard they audit
- ✓Past allocations exist for every active client for at least one cycle
- ✓A sample of 20 allocations is checked by a planner for competence, rotation and conflicts
- ✓A real planning period gives a plan the planners accept, with every exception explained
- ✓Integrations write confirmed bookings back to the certification platform and calendars
Running a proof of concept before purchase gives you an early trial of this process on your own data.
Should you run old and new systems in parallel?
For a limited period, yes. Planning one real month or quarter in both tools shows whether the data and the rules are right, and gives planners confidence. Keep it short and time-boxed, because two live schedules soon drift apart and create double bookings.
MythWe can clean the data after go-live.
RealityDirty competence data produces invalid allocations from day one. Clean at the source first.
MythOnly future audits need to move.
RealityRotation and conflict checks need past allocations. Without history, the system cannot apply them.
MythParallel running should last until everyone is comfortable.
RealityLong parallel runs create conflicting schedules. Agree a fixed period and exit criteria.
How do you keep data in sync after audit scheduling data migration?
Once live, avoid a second migration by design. Decide which system owns each record, connect them through an API or webhooks, and stop keeping side spreadsheets. See our guide to certification ERP integration for common patterns, and our overview of certification body management software for how the layers fit.
See how ScheduleAI's audit scheduling software applies these rules across a whole programme in minutes.
ScheduleAI imports clients, audits, auditors and competence through its REST API, webhooks or Intact integration, and the free two-week custom demo runs on your own data, which surfaces migration gaps before you commit.
Book a demo Estimate your savingsQuestions
What data is essential for a new scheduling system?
Clients and sites, audit programmes with due dates and audit time, auditor competence with dates, accreditation per standard, past allocations and conflicts of interest.
How many years of audit history should we migrate?
At least one full three-year certification cycle for every active client, and longer if your rotation rules look further back.
Should we clean data before or after migration?
Before, at the source system. Loading dirty competence data produces invalid allocations from the first plan.
How long does an audit scheduling data migration take?
It depends mostly on the number of sources and the state of competence data. The illustrative plan in this article runs to about eight weeks plus a hypercare period.
How do we know the migration worked?
Plan a real period in the new system and compare with your manual plan. If planners accept it and every exception is explained, the data is fit for use.