Why schools replace separate tools
The reasons are usually practical rather than technical. Teachers enter the same result in a gradebook and again in a report. A portfolio app holds the evidence, a separate gradebook holds the marks, and a third document holds the comments, so nobody can see one child's learning in one place. Reporting is slow, analytics are thin, families have several logins, or the tools cannot follow the way a programme actually works.
Notice which of these is your reason, because it decides what a replacement has to do. A school replacing a tool to cut duplicate entry needs a different product from one replacing it for stronger programme-specific workflows.
First ask whether replacement is the answer
Before starting a migration, check whether the problem is the tool or the way it is used. A gradebook that teachers avoid may need better set-up and training. A portfolio app that fills with untagged photographs may need clearer rules. Replacement moves the problem if the habits come with it.
Migration questions to settle first
Identify what is held in the old tools before choosing a migration approach, and decide for each item whether it moves, is archived or is dropped.
| Item | Question to settle |
|---|---|
| Historical grades | How many years must be searchable in the new system, and how many can live in an archive? |
| Portfolio media | Can the originals be exported, at what quality, and with their dates and captions? |
| Comments and reflections | Are they included in the export, or only the marks? |
| Student identifiers | Which identifier links a child across systems, and is it consistent? |
| Permissions | Who could see what, and can that be reproduced? |
| Family access | How will families keep access to what they were given, and who tells them? |
| Report templates | Which templates must be rebuilt, and who signs them off? |
Choosing a migration approach
There are three common patterns. Import what you can and archive the rest. Run the old and new systems in parallel for a term. Or start fresh for the new cohort and keep the old system read-only for history. Each has a cost: importing takes cleaning and testing, parallel running doubles the work, and starting fresh leaves history somewhere else. Choose by asking what a teacher, a family and an auditor will need to find in three years.
Where skodle fits
This section names our own product, so weigh it accordingly. Everything above holds whichever tool you move to.
For the move in, skodle's Migration Centre imports students and staff from CSV, TSV, Excel or JSON files, up to 5,000 rows at a time, through upload, column mapping, validation and a preview before anything is written. It matches on email address, so a re-run does not duplicate people, and every import is audited. An older importer on the roster page also creates invite codes. The rest of a school's set-up, and the gradebook and portfolio features themselves, are described on the assessments and gradebook and student portfolios pages.
The limits, and they decide the plan. Nothing imports historical grades, attendance history, portfolio posts or media, comments, reports or fees, so a school replacing those two tools should expect to archive the old records outside skodle and begin the new year's records fresh. An import has no rollback. The pricing page promises onboarding and data migration in every plan: today the tooling behind that covers people, and anything more is manual work that should be agreed in writing before you commit. skodle does not carry the official IB route for registration and coursework submission either.
Pricing is per user, per month: $2 per user for up to 150 users, $3 from 151 to 500 users and a custom plan above 500, with parents at half the rate and every feature in every plan. Every new school starts with a free 30-day trial, so the fair test is your own data. See pricing.
Plan the transition
A dependable plan has a shape. Run a data audit, define what must migrate, clean the records, test imports on a copy, pilot with one year group and train staff before the pilot, not after.
- Audit the data: what exists, in what state, held where
- Decide what moves, what is archived and what is dropped
- Clean identifiers and duplicates in the old system first
- Test an import on a copy and check a sample by hand
- Pilot with one year group across a full assessment cycle
- Train staff before the pilot, and give them a named person to ask
Tell families and staff early
Families see the change most directly, through new logins and a different portfolio. Tell them what is happening, what they will keep, when, and who to ask. Staff need to know what the new tool changes in their week and what it does not. A rumour that history is being lost will spread faster than the plan.
Risks, and how to reduce them
The main risks are losing history, breaking family access, timing the change badly and underestimating the training. Reduce them by keeping the old system read-only until a full cycle has completed, by never changing during report writing, and by measuring after a term whether the reason you started has actually improved. The wider project view is in school software consolidation.
