What 5 K-12 Tech Directors Tell Us They Wish They'd Asked Before Signing

About six to nine months into using our platform, Tech Directors tend to send us a note. The wording varies, but the structure is almost always the same: "this would have been easier if I'd known to ask about X before signing." After a year of those notes, five patterns repeat clearly enough that they deserve their own article.

This piece is the retrospective companion to the 10-question vendor evaluation framework we published Tuesday. That guide is forward-looking, written for directors who are actively comparing platforms. This one is written from the receiving side of those year-1 conversations, for directors who are either mid-evaluation right now or who signed a contract recently and are starting to wonder whether they asked the right questions. For implementation-specific prep, our migration data checklist is the operational companion to both.

If you are currently in an evaluation for switching K-12 device management software, ask these five questions before you sign anything.

Pattern 1: "I Wish I'd Asked What Specifically Transfers From Our Existing System, Field by Field"

The demo answer is always some version of "we handle migration." Every vendor says it. It sounds complete. It is not.

What the retrospective conversation reveals, usually around the six-week mark after go-live, is that "we handle migration" was describing the process, not the output. The question that actually matters is: which fields transferred, which were rebuilt manually, and which are still sitting in the legacy system because no one documented that they existed?

The specific items that come up repeatedly in these conversations are comment threads attached to tickets, file attachments (photos of device damage, signed intake forms, repair authorization documents), and granular permission rules that were configured over years by someone who is no longer in the district. None of those are standard database columns. They require either explicit migration logic or manual reconstruction, and districts usually find out they didn't transfer during the worst possible moment: week three of go-live, when a parent disputes an old damage charge and the documentation that would resolve the dispute is locked in a system the district no longer has active access to.

What a good vendor answer looks like in a demo is specific. You want a field-level migration spec for your exact source platform, not a general statement about migration capability. You want a named list of fields that do not transfer (not because the vendor is hiding something, but because some genuinely can't be programmatically extracted and that is honest information you need). And you want a plain-English document you can hand to your team so they know what they are walking into before day one.

For Asset Management, this matters most because device records often carry years of layered history: repair logs, loaner assignments, damage notes, warranty documentation. A clean device record that imports device ID and serial number but drops everything else forces your team to spend the first weeks of operation rebuilding institutional knowledge that already existed.

Our migration team works from a source-specific field map before any data moves. We name what transfers, what requires manual reconstruction, and what we recommend archiving in a read-only export before the legacy system goes dark. The full drill-down on what to document before you move is in our migration data checklist.

Ask any vendor you are evaluating: "Can you give me the field-level transfer spec for our specific source system before we sign?" The answer will tell you a great deal.

Pattern 2: "I Wish I'd Asked How the SIS and MDM Sync Actually Behave at Sync Time, Not in the Brochure"

The brochure says "live SIS integration." Sometimes it even says "real-time." What districts tell us in year-one retrospectives is that they did not ask a follow-up question, and the follow-up question is the entire thing.

SIS sync behavior is not a binary feature. It has a cadence, a conflict-resolution logic, a set of edge cases, and a list of fields it does and does not touch. The pattern we hear is that these details were never surfaced during the sales process and only became visible when something broke in production.

The edge cases that create the most operational friction are predictable ones. A student transfers buildings mid-year. The SIS reflects the change on Tuesday. The device asset record reflects it on Friday because the sync runs nightly. On Wednesday, someone pulls a device report by building, and the numbers are wrong, and no one immediately knows why. Or a student ages out of a grade band and their user role changes in the SIS from student to alumni. Does the device management platform handle that gracefully, or does it throw an error and queue the record for manual review?

The other case that comes up repeatedly involves staff who were students the prior year. Role changes across the student-staff boundary require specific handling because permission levels, portal access, and billing logic all differ. A sync that treats a role change as a new record versus an updated record produces very different outcomes.

What a good vendor answer looks like is specific: exact sync cadence (real-time event-driven, hourly batch, nightly batch), named conflict-resolution behavior when SIS and local records disagree, and an honest list of fields that sync versus fields that require manual update. If a vendor cannot tell you the conflict-resolution logic off the top of their head, that is worth noting.

For User Management, stale SIS data is the most common source of what we call Friday-afternoon-emergency tickets: the "wait, who actually has this device right now?" problem. The question is usually not catastrophic, but it is urgent, it lands on already-stretched staff, and it is entirely preventable with honest pre-purchase conversations about sync behavior.

We sync on a configurable cadence and can walk you through how each edge case is handled before you sign. Ask us, and ask any other vendor you are evaluating, to walk through the building-transfer scenario and the role-change scenario explicitly.

Pattern 3: "I Wish I'd Asked What Historical Reporting Actually Looks Like 18 Months In"

Demo dashboards look excellent. They are designed to. The retrospective question is different: when your board asks for a three-year repair-cost trend broken down by building, can you produce it in forty minutes without calling support?

The pattern we hear here is not that vendors lied about reporting. It is that reporting was evaluated on the demo environment, which is populated with clean, recent, well-structured sample data. Production environments are messier. They contain records from the beginning of the contract, data that was migrated from a prior system in varying states of completeness, buildings that were renamed or reorganized, and students who appear under multiple IDs because of data entry inconsistencies. Historical reporting has to work through all of that.

The specific things that surface in year-one retrospective conversations are: rolling-window data limits (some platforms store ninety days of activity data at full granularity and archive the rest in a format that requires a support request to access), live-computed versus cached reports (a live-computed report against three years of district data can take long enough that the session times out), and the behavior of reports when building or tech assignments have changed over the reporting period. If Tech 3 was responsible for a building from August through November and Tech 7 took over in December, does a full-year report attribute correctly, or does it assign everything to the current assignment?

What a good vendor answer looks like: they can show you an anonymized sample export from a district that has been on the platform for eighteen months or more. They can tell you explicitly whether there are rolling-window limits and what they are. They can describe how the reporting layer handles mid-year organizational changes. If they cannot answer those three things during the demo, ask to schedule a follow-up with someone technical.

Reporting is most valuable at budget season, which is exactly when you do not have time to reconstruct data or wait on a support ticket. Districts who cannot pull defensible multi-year trends end up either over-requesting budget because they are padding for unknowns, or under-defending it because they cannot substantiate the ask. Both are avoidable.

We retain full data at full granularity across the life of your contract. Reports run against your actual historical data, not an archive. Ask us to show you a sample export.

Pattern 4: "I Wish I'd Asked What Families See in the Portal and What Happens to Their Balance During the Migration"

The parent and student-facing experience tends to be the last thing evaluated during vendor selection and the first thing that causes visible problems during go-live.

The pattern we hear in year-one conversations is that Tech Directors focused their evaluation on the administrative interface, the device records, the ticketing workflow. Completely reasonable. That is where they spend their day. But families do not interact with any of that. They interact with a payment portal when they receive a damage invoice, and a self-service interface when their student needs to report a broken device or check a repair status.

The cutover window is where this becomes acute. During the week or two around go-live, families may attempt to pay an outstanding invoice, check a balance, or log in to see the status of a repair ticket that was open in the old system. If the family portal is unavailable, families assume there is a billing problem. If the invoice numbers changed during migration, families cannot find their record. If old invoices are not visible in the new portal, families who paid in the previous system have no confirmation history and dispute the payment.

What a good vendor answer looks like is a documented cutover plan specifically for the family-facing side. That means: what is the portal availability window during migration, do invoice numbers carry over or regenerate, and can families view invoices that originated in the prior system. It also means communication templates for the transition that a district can send to families before the cutover, so the experience is contextualized rather than confusing.

The Self-Service Portal handles both ticket deflection and the parent invoice and payment interface in our platform. We treat both as first-class parts of the go-live plan, not afterthoughts. Our cutover documentation includes family-facing communication templates and explicit answers to the invoice continuity question for each source platform we migrate from.

Payment disruption during go-live lands on the Tech Director's desk as two problems simultaneously: a billing complaint from a parent and an integration question from finance. Asking one question before signing prevents both.

Pattern 5: "I Wish I'd Asked What Year-2 and Year-3 Pricing Actually Looks Like"

Year-one pricing is what appears in the quote. That number is real. The retrospective question is about what happens to it.

The pattern we hear from districts who came to us after a bad fit elsewhere is that the original board ask was built around the year-one number, and the renewal landed materially higher. The reasons vary. Enrollment grew and the platform is priced per student above a threshold. Modules that were bundled into the initial contract were unbundled at renewal as the vendor restructured their packaging. An annual renewal escalator was written into the contract at a percentage that seemed reasonable in year one and compounded uncomfortably by year three. In each case, the district's Technology Director had defended the original number to their board and was now in the uncomfortable position of explaining why the three-year budget projection needed to be revised upward.

What a good vendor answer looks like is written and specific. Published pricing tiers, not a custom quote that obscures where the breakpoints are. Written renewal escalator language in the contract, not a verbal assurance that pricing stays consistent. An explicit list of what is included in the current contract and a statement about whether that bundling is stable at renewal.

The questions to ask directly are: what happens to my per-student rate if enrollment grows by ten percent? What is the renewal escalator language in the contract? Have any modules been unbundled from standard packages in the last two years?

We publish our pricing publicly. There are no custom quotes that exist only in a PDF. The breakpoints are visible, the renewal structure is documented, and we are not going to tell you something in a demo call that contradicts what is written. Use our cost estimator to model your specific enrollment tier and see the actual numbers before any conversation with our team.

The multi-year budget conversation is hard enough without having to revisit it because a renewal came in thirty percent above what was originally defended to a board.

How to Apply These Five Questions to Your Current Evaluation

Print this list. Take it to your next demo. Ask each question explicitly and listen for the difference between a specific answer and a reassurance. A vendor that has run year-one retrospectives with their customers will have ready, specific, and sometimes uncomfortable answers. They will know which fields do not migrate from your source system because they have migrated from it before. They will be able to describe sync edge cases because those edge cases have occurred in production and were resolved. A vendor that has not had those conversations yet will reach for a brochure.

These five patterns connect directly to the forward-looking questions in the 10-question vendor evaluation framework from Tuesday. The retrospective questions are the same questions asked after the fact. Asking them before signing collapses the learning curve.

One practical note on our side: we built the handling for these edge cases specifically because we kept hearing about them in year-one retrospectives from districts who switched to us after a bad fit elsewhere. Field-level migration logging, sync edge-case handling, multi-year historical reporting, family portal cutover planning, and transparent renewal language are not marketing features. They exist because someone paid a real operational cost when they were missing. Part of our team came up through K-12 IT before building on the vendor side, which is the honest reason we know what the cost looks like when these things go wrong. We mention that once, for transparency, not as a credential.

The features that address these patterns are Asset Management, User Management, Reporting, Self-Service Portal, Help Desk, and Incident Management. The reason they connect to these five retrospective questions is that the questions map to real operational failures, and the features were designed around preventing those failures.

Frequently Asked Questions

What is the most common reason K-12 districts switch device management platforms in year 2 or 3?

The most consistent pattern is a mismatch between what the platform was evaluated for and what the district actually needs by year two. That often means reporting limitations that only surface at budget season, SIS sync behavior that creates manual cleanup work, or a renewal price that exceeded what was projected. A smaller but persistent subset switches because the family-facing experience created more support burden than it relieved, not less.

How do I know if my current platform is actually serving my district's needs?

The clearest signal is whether your team is maintaining parallel records outside the platform, whether those are spreadsheets, shared drives, or notes in a separate system. A platform that is actually serving your district should be the single authoritative record for device history, user assignments, repair status, and invoicing. If your team is maintaining anything alongside it to fill gaps, those gaps are worth examining.

Can we migrate mid-school-year, or do we have to wait for summer?

Mid-year migrations are operationally harder but not impossible. The primary risk is the family-portal disruption described in Pattern 4, since payment activity tends to be higher during the school year. Districts that migrate mid-year successfully tend to do so by running a parallel read-only access window in the legacy system for four to six weeks, giving families continuity while the new platform comes live. Summer is easier because device activity and family-facing interactions are both lower, but waiting for summer is not the only option.

What does a year-1 retrospective conversation typically look like with a new vendor?

In practice, it is usually informal: a note, a support ticket that turns into a broader conversation, or a check-in call around the anniversary of go-live. The districts that use it well treat it as a structured review: what were the original goals, what happened during go-live, what is working in production, and what edge cases were not anticipated during the evaluation. The five patterns in this article are a composite of what comes up in those conversations consistently, not exceptions.

How much should I expect to pay for K-12 device management software?

Pricing varies enough across platforms and district sizes that a single number is not useful. The more important questions are: is pricing per student, per device, or per building, and where are the tier breakpoints relative to your enrollment? Is the quoted price a bundle or a base that grows as you add modules? What is the renewal escalator? We publish our pricing publicly and provide a cost estimator so you can model your specific situation before any conversation with our team.

Conclusion

Every K-12 Technology Director has a year-one retrospective about every major platform they have signed. The only question is whether the lessons from it are catastrophic, meaning they trigger a second switch, a board conversation, or a family-billing crisis, or operational, meaning they are things that got worked out and documented and made the team more effective going forward.

Asking these five questions before signing does not guarantee a perfect implementation. It does collapse the distance between catastrophic and operational by surfacing the edge cases that have a documented cost before they occur in your district's production environment.

If you are currently evaluating platforms, bring these five questions to your next demo. Ask them of every vendor on your list, including us. A platform that has lived through enough year-one retrospectives to have specific, ready answers to all five is a platform that has earned the right to be trusted with your district's operational data. Book a demo, bring the list, and see how we answer.