How to start without migrating the whole school first

A training center may already work in spreadsheets, calendars, messengers, a previous system, or a mix of all of them. That does not mean the first step must be a full migration.

The safer first step is to prove that the workflow fits the school.

Why full migration is the wrong first step

Moving every record before understanding the workflow creates unnecessary risk.

It can force the team to spend time on:

• cleaning old spreadsheets;
• deciding which historical records are still useful;
• preparing student and teacher lists;
• rebuilding groups and schedules;
• checking old balances;
• explaining old payment exceptions;
• importing data before the team knows whether the process fits.

That work may be needed later, but it should not block the first evaluation.

Start with demo data

Use demo data first when the goal is to understand how the system behaves.

Demo data lets the owner and administrators inspect a prepared training center:

• how lessons appear in the schedule;
• how attendance is recorded;
• how invoices are calculated from lessons;
• how payments change student balances;
• how reports reuse the same history;
• how teacher payout information can be explained.

This answers the first question: does the connected workflow make sense for the school?

Then add one real slice

After demo data is clear, add a small real workflow instead of the whole school.

A useful first slice can be:

• one branch;
• one course;
• one group;
• one teacher;
• several students;
• one short schedule period;
• a few realistic attendance statuses;
• several payments and balances;
• one billing period.

This is enough to test the real school rules without turning the trial into a migration project.

What to validate with the small scenario

Use the small scenario to check whether the system can answer practical questions:

• Can the administrator create and adjust the schedule?
• Can attendance be marked in the lesson context?
• Can missed or transferred lessons be handled according to school rules?
• Can invoices be explained from lessons, attendance, prices, and discounts?
• Can automatic payment allocation explain debt, credit, and balance changes?
• Can the owner see useful reports without manual spreadsheet work?

If the answer is yes, the school has evidence that the workflow is worth expanding.

Keep billing under control before expanding

Billing is usually the most sensitive part of adoption. A schedule mistake is inconvenient. A billing mistake affects trust and cash flow.

Before adding more students, run a billing check before go-live:

• compare invoice totals with the current process;
• check attendance-based charges;
• test discounts;
• record partial payments;
• verify previous debt;
• verify overpayments and credit;
• confirm that reports use the same data.

Only expand after the team can explain the financial result.

Import later, not first

Import is useful when the school already understands what it wants to move.

Possible import stages:

1. Core directories: students, teachers, groups, branches, rooms.
2. Current schedule and active groups.
3. Current balances and open invoices.
4. Payment history that is still operationally useful.
5. Older history only if it is needed for reporting or audit.

Not every old record has to be moved. Some history can remain archived in spreadsheets or the previous system if the school only needs it for reference.

When full migration makes sense

A broader migration makes sense after the team has confirmed:

• the workflow matches daily operations;
• billing rules are represented correctly;
• administrators can explain balances;
• owners can see useful reporting;
• staff roles and access are clear;
• the school knows which old data is worth importing.

At that point migration becomes a controlled operational step, not a leap of faith.

Result

You can evaluate Intelligence Cloud without moving the whole school first.

Start with demo data, validate one real workflow, check billing carefully, and only then import more records. This reduces risk, protects the team's time, and makes the adoption decision based on real workflow evidence.