Childcare technology migration playbook: avoid migration mistakes that break operations

Switching childcare platforms is one of those projects that looks simple on the sales call and turns into a mess three weeks in. The demo shows a clean dashboard, someone promises "we'll handle the import," and everyone signs off feeling good. Then the data lands sideways, half the enrollments are missing their start dates, two families show up as duplicates, and your director is manually re-entering attendance while parents are asking why their app won't log in.

Most migration failures aren't technology failures. They're planning failures. The vendor didn't lie about their software — the center just underestimated how tangled its own data actually was, and nobody built a real plan for cutover day. This is a systems problem, and it needs to be treated like one.

What follows is a full childcare technology migration playbook: how to vet vendors, how to map your data so nothing gets lost, how to phase the cutover with real rollback triggers, and how to govern integrations so your history survives the move.

Why migrations quietly break operations

The core issue is that childcare data isn't clean. It grew organically over years. A family record might live in your billing system, but emergency contacts are in a paper binder, and immunization dates live in a spreadsheet someone built in 2021. When you migrate, you're not moving one clean database — you're merging three or four messy sources that never really agreed with each other.

The second issue is timing. Centers tend to migrate mid-year because that's when they finally have bandwidth, which is exactly the wrong time. You're cutting over while tuition is actively billing, attendance is actively logging, and licensing records need to stay pull-ready. There's no quiet period in a working center.

A typical example: a center exports their family list, imports it, and everything appears fine. Two weeks later they realize the old system stored sibling relationships as a linked field and the new system doesn't — so sibling discounts silently stopped applying. Nobody caught it until a parent called about a bill that jumped $180. Multiply that across 40 families and you've got a billing credibility problem that takes months to recover from.

That's the pattern with bad migrations. The damage isn't loud on day one. It leaks out over weeks, and by then you can't tell whether a number is wrong because of the migration or because of a normal billing change.

Vendor RFP checklist: what actually separates good vendors from demo-good vendors

Most RFPs ask about features. Features are the least important thing. Every modern platform does attendance, billing, and messaging. What breaks migrations is the stuff vendors don't put on the pricing page.

Here's what your RFP should force them to answer in writing:

1. 1
   Data export in your format, on demand — Can you pull your full data out, anytime, in CSV or via API, without paying or asking permission? If leaving is hard, that tells you how they'll treat you.
2. 2
   Historical record retention — Where do closed enrollments, past invoices, and old attendance go? Can you still pull a three-year-old attendance record for a subsidy audit? Ask them to show you.
3. 3
   Who does the import, and who validates it — "We handle migration" often means they run a script and hand it back. Get specific: who checks that the numbers match the source?
4. 4
   Sandbox / test environment — Will they load your real data into a test instance before go-live so you can verify it? If not, you're testing in production, which is the whole problem.
5. 5
   Field mapping documentation — Can they show you exactly how each of your old fields maps to their new ones? This is where sibling links, discount rules, and custom notes get dropped.
6. 6
   Rollback support — If the cutover fails, what's the path back? A vendor who's never been asked this question is a red flag.
7. 7
   Integration list — Which payment processors, background-check services, and state reporting tools do they connect to natively, and which need custom work?

Score vendors on these, not on how pretty the parent app looks.

“

Score vendors on these written answers, not on the demo.

The app matters, but it won't save you if your billing history evaporates.

Build a canonical data model before you export anything

This is the step almost everyone skips, and it's the one that determines whether your migration works. Before you touch either system, define what your core records are — independent of any software. That definition is your canonical data model. Both the old export and the new import get mapped to it.

Families — the household unit. Parents/guardians, contact info, emergency contacts, authorized pickups, sibling relationships, subsidy/agency links. Everything else hangs off this record.

Enrollments — the link between a child and a program or room, with a start date, end date, schedule, rate plan, and status (active, waitlisted, withdrawn, graduated). Historical enrollments matter as much as active ones.

Invoices — every charge, credit, discount, and payment, tied to a family and a date. This includes closed and paid invoices. You need the history for disputes, taxes, and audits.

Attendance — daily check-in/check-out records tied to a child and enrollment, with the staff member and timestamp. This feeds ratios, billing verification, and licensing.

Write down every field you currently use for each entity, and every relationship between them. The relationships are what break — sibling links, which invoices belong to which enrollment, which attendance records belong to which room. If your governance already defines how these records are structured and retained, this step goes much faster. If it doesn't, this is a good moment to fix it, and the principles in what good childcare data governance looks like are worth reviewing before you start mapping.

A canonical model turns migration from "hope the import works" into "verify the import matches the model." You stop trusting and start checking.

The phased migration and cutover playbook

Big-bang cutovers — flip everything at midnight and pray — are how centers end up re-entering a week of attendance by hand. A phased approach costs more time upfront and saves you from the disaster.

1. 1
   Freeze the model, not the operation. Finalize your canonical data model and field mapping. Don't stop billing or attendance — just stop making structural changes to how you record things.
2. 2
   Do a full test import into a sandbox. Load real (or realistically representative) data into the new system's test environment. Not sample data — your data.
3. 3
   Reconcile. Compare counts and totals between old and new. Number of active families, number of active enrollments, total outstanding balance, attendance record counts for a sample month. If the outstanding balance doesn't match to the dollar, stop. Don't proceed on a mismatch.
4. 4
   Run both systems in parallel for a short window. For one to two weeks, record attendance and billing in both. Yes, it's double work. It's also how you catch discrepancies while you still have a working fallback.
5. 5
   Pick a low-traffic cutover point. End of a billing cycle, ideally a Friday afternoon or a closed day. Set a hard data freeze on the old system so nothing changes after your final export.
6. 6
   Final export and import. Pull the definitive dataset, import, reconcile again against the same counts. Sign off in writing when they match.
7. 7
   Go live with the old system in read-only. Don't delete anything. Keep the old system accessible for at least a full billing and licensing cycle so you can pull history if something's missing.

This diagram shows the phased migration workflow.

Rollback triggers — decide these before you cut over

1. 1
   Outstanding balances don't reconcile within a small, agreed tolerance
2. 2
   More than a handful of families are missing or duplicated
3. 3
   Attendance history for the current licensing period didn't come across
4. 4
   Payment processing fails to charge correctly on the first live run
5. 5
   Staff can't complete a normal check-in flow within the first hour

If any trigger fires, you revert to the old system — still live because you didn't delete it — fix the issue in the sandbox, and re-attempt. This only works because you kept the old system running. That's the whole point of not doing a big-bang.

Integration and API governance: protecting your history

The part of migration that ages worst is integrations. Payment processor, background-check vendor, state subsidy reporting, accounting sync — each connection is a place where data flows out of your system, and each one needs rules.

What data leaves, and where does it go? Every integration should have a documented purpose and a documented data scope. Your accounting sync doesn't need child attendance records. Your parent messaging tool doesn't need full invoice history. Scope each connection to the minimum it needs. This limits your exposure and makes the next migration cleaner.

What happens to history when an integration changes? When you switch payment processors during a migration, the transaction history often lives with the old processor, not your new platform. If you don't export and store that history under your own control, you've lost your billing paper trail. Before you cut any integration, pull its historical data out and attach it to your canonical records.

A practical rule: your center should own a complete, exportable copy of families, enrollments, invoices, and attendance that doesn't depend on any single vendor staying in business. Integrations should feed that record, not replace it. When a vendor holds the only copy of your history, you've handed them leverage over your operation.

This matters even more for multi-site operators, where inconsistent integrations across locations create reconciliation headaches. If you're running or growing multiple sites, the coordination challenges compound, and the approaches in scaling without quality loss across multiple sites apply directly to how you standardize systems before migrating them.

A real scenario

A two-site preschool with around 130 enrolled children moved off an aging billing tool onto a modern platform. Their first attempt was a big-bang cutover over a weekend. By Monday, roughly 18 families showed as duplicates because the two sites had overlapping family IDs, sibling discounts had dropped entirely, and about three weeks of attendance for the infant room hadn't imported.

They spent the next month cleaning it up manually — the director estimated close to 40 hours of re-entry and reconciliation, plus a round of parent billing complaints that shook trust in the center's administration.

The second time — after they scrapped the first attempt and reverted — they built a canonical data model first, ran a sandbox import, and reconciled totals before committing. The duplicate issue surfaced in the sandbox, where it cost nothing to fix. Sibling discount mapping was caught during reconciliation because the discounted revenue total didn't match. Cutover happened on a Friday with the old system left in read-only for six weeks. The go-live was, in the director's words, "boring" — which is exactly what you want a migration to be.

The difference wasn't the software. Both attempts used the same new platform. The difference was the model, the reconciliation, and the willingness to roll back the first time instead of pushing through a broken cutover.

When a migration makes sense — and when to wait

When it makes sense: your current system genuinely can't do something you need — multi-site reporting, subsidy handling, proper attendance-to-billing verification — you have a defined low-traffic window, and you have someone who can own the reconciliation work. Don't migrate because a competitor's app looks nicer.

When it's a bad idea: mid-licensing-cycle, right before an inspection, during peak enrollment season, or when your only reason is a discount offer with a deadline. A vendor pressuring you to cut over fast to lock in pricing is pressuring you to skip the exact steps that prevent disasters.

Who should not do this without help: any center whose data lives in more than three places with no single source of truth. Clean up and consolidate first. Migrating messy data just moves the mess into a system you understand less well.

A related caution: migrations that touch billing directly affect cash timing. If your final invoices, credits, or subsidy charges don't map correctly, you can create a cash gap that has nothing to do with your actual revenue. Keeping your forecasting steady through a system change is worth planning for, and the tuition and refund practices in avoiding cashflow surprises pair naturally with a migration timeline.

Where good operational software helps — and where it doesn't

Modern operational platforms make migrations easier in real ways: self-serve exports, sandbox environments, reconciliation reports, and integrations that scope data properly instead of dumping everything everywhere. Some platforms also use automation to flag likely duplicates, mismatched totals, or dropped relationships during import — the kind of checks that are easy to miss when you're manually scanning 60 rows deep.

But the software doesn't build your canonical model for you, and it can't decide your rollback triggers. It won't know that your sibling discount logic is non-standard or that one site used a different rate structure. Those are operational decisions that come from knowing your own business. The tool handles the mechanics; you have to bring the map.

The centers that migrate well treat the platform as an execution engine for a plan they already built. The ones that struggle treat the platform as the plan — and find out on Monday morning that "we'll handle the import" meant something very different than they hoped.

Bringing it together

A migration is a stress test of how well you understand your own data. If your families, enrollments, invoices, and attendance are clearly defined and cleanly related, moving them is mostly mechanical. If they're not, no vendor and no software will save you — the mess just relocates.

Do the unglamorous work first: define your canonical model, put real vendor accountability into your RFP, phase the cutover with reconciliation gates, decide your rollback triggers before you need them, and govern your integrations so you always own a complete copy of your own history. Do that, and the go-live becomes boring. Boring is the goal. Boring means your Monday looks exactly like your Friday, and the parents never knew anything changed at all.