Switching Preschool Software: A Data and Billing Cutover Checklist

Switch preschool software by defining which records must move, testing them in the new system, and assigning one live system to each operational task during the transition. Billing needs particular care: reconcile balances and scheduled payments before cutover so a family is neither charged twice nor missed.

The work is easier to manage when “migration complete” means something specific. A child’s name appearing in the new app does not prove that the correct guardians, pickup people, classroom, or billing arrangement are connected.

This checklist is for preschool directors preparing a controlled transition. The timeline depends on your records, vendors, and workflows; it does not assume every school can switch in a fixed number of days.

Agree on the migration scope before exporting

List the information needed for the first day in the new system, and separate it from historical records that must remain accessible elsewhere.

Ask the new vendor to confirm what it can import and in which format. Do not assume an export from one system can be read completely by another.

Keep the decision in writing. A clear scope prevents “we thought that was included” from appearing on go-live morning.

Protect the export as carefully as the original

An exported spreadsheet can contain the same sensitive information as the application it came from.

Use approved storage and transfer methods, limit access to the people doing the work, and avoid copying children’s records into personal email or public writing tools. Use fictional records for early testing where possible.

The FTC’s business data-security guidance recommends knowing what personal information the business holds, limiting unnecessary collection, restricting access, and maintaining an appropriate retention policy.

That does not establish a preschool-specific retention period. Confirm the requirements that apply to your records and contracts before deciding what to retain or dispose of.

Create an acceptance sheet for the imported records

For each record type, define what a successful import looks like.

A practical acceptance sheet can include:

• Source record identifier
• Destination record identifier
• Required fields checked
• Relationship or classroom links checked
• Missing or ambiguous fields
• Reviewer
• Resolution and sign-off date

Start with fictional test records and a small approved sample before a full import. Include awkward cases: two children with similar names, siblings, multiple guardians, an inactive enrollment, and a pickup contact whose access changed.

Then reconcile the full import. Compare record counts, look for duplicates, and review critical relationships and required fields. Sampling helps expose problems early; it does not establish that every remaining record is correct.

Do not approve an import merely because the row count matches. Forty children connected to the wrong guardian records is still a failed migration.

Give every live workflow one owner

Running both systems during a transition can be useful, but “parallel” needs a definition.

For each task, record which system is authoritative and when that changes:

These are examples to adapt, not instructions to activate both platforms at once. Shadow testing should not send duplicate notifications or initiate real payments.

Keep a change log after the initial export. New enrollments, withdrawals, contact changes, and corrected care information can otherwise disappear between the exported snapshot and launch.

Reconcile preschool billing before enabling collections

Choose a billing cutoff and work through every open account with the appropriate finance owner.

Check:

1. Issued invoices and their outstanding balances
2. Payments already completed
3. Payments still processing
4. Approved credits and deposits
5. Scheduled automatic payments and retries
6. Which system will handle refunds or disputes relating to older payments

Record the chosen treatment of each item. An opening balance should not duplicate a transferred unpaid invoice. A processing payment should not trigger another collection in the new system.

For example, imagine a fictional family has a $900 invoice and a $900 payment still processing in the old system. Moving a $900 “unpaid balance” into a new active autopay schedule could create a duplicate charge. Resolve the payment’s status and collection ownership before activating the new attempt.

Ask both vendors how payment credentials and authorizations are handled. Do not assume saved cards transfer. Never ask families to email card or bank details to help with the move.

Test the day the staff will actually have

Use sample records to walk through:

• A guardian receiving the correct invitation
• A teacher finding the right classroom roster
• An authorized staff member checking a child in
• Staff locating current care information
• A report reaching the intended family
• A billing user reviewing a sample invoice and payment status
• A director finding the information needed to correct an error

Include the devices the team will use. A workflow tested only on a director’s laptop may behave differently on the classroom tablet or check-in kiosk. For report-specific checks, such as photo recipients and corrections after sharing, see our preschool daily reports checklist.

Record each result as passed, needs a fix, or not tested. Keep a named owner for unresolved items.

Tell families exactly what changes and when

Use a short, factual notice with verified links.

Subject: Our preschool app changes on [date]

Hi Families,

Starting [date], [Preschool name] will use [new system] for [specific functions].

Please complete [required action] through [verified invitation or instructions] by [date]. For payments, [explain the verified transition and any action needed without including private account details].

Until [cutoff], continue using [old system] for [specific functions].

If you need help, contact [person and details]. We will confirm when the new process is active.

[Director name]

Check this message against the actual cutover plan. Do not announce app availability, transferred records, or saved payment methods before those details are confirmed.

Make a go-or-pause decision before launch

Before launch, confirm that the school can operate the agreed workflows:

• Required records and relationships are reviewed
• Staff access is appropriate
• Attendance and communication tasks have been tested
• Billing ownership and open balances are reconciled
• Families have accurate instructions
• Staff know how to get help
• A documented fallback exists for unresolved operational problems

If a critical check fails, pause the affected change and use the approved fallback. A calendar date alone is not a reason to accept an unverified record or payment setup.

After launch, reconcile the first attendance day, first report cycle, and first billing run. Keep a short issue log until the remaining problems are resolved.

Keep historical access under a defined plan

Before canceling the old subscription, confirm that required exports are complete, readable, appropriately protected, and retrievable. Check what access remains after cancellation and what the contract permits.

Do not use a universal “keep it for one year” rule. Retention needs depend on record type and applicable requirements. Document the plan with the people responsible for the preschool’s compliance and finances.

Test your preschool cutover plan

Bloomily’s switching page describes importing child, family, and pickup information from existing lists, with review before saving; families add a card themselves when they first pay. Explore Bloomily for preschools and bring a fictional record set plus a sample billing cutoff to a demo. Confirm what transfers, what stays in an archive, and what your team needs to review before going live.