English Learner Program Compliance Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does identification get scoped as a digital form instead of a clock?

Ask for a system to fix identification and almost every proposal will offer to replace the paper home language survey with an online one. That is worth doing and it is not the problem. The problem is the clock. A qualifying answer on the survey starts a screening obligation with a deadline computed from your state's window and the enrolment date, and whether that screening happens depends entirely on whether somebody at that campus noticed the form during a week in August when the office is processing four hundred enrolments.

A form digitises the artifact. What you need is a task chain: the qualifying answer creates a screening task with a due date, an assigned person at that campus rather than a shared mailbox, an escalation schedule, and a district level view of every open identification task across every campus. That single screen is usually the first time a director can answer how many students are currently unscreened without sending emails and waiting a week.

The same distinction runs through the build. Placement is a decision recorded with who made it and on what evidence. Parent notification is an event with a date, a language, a delivery method and a stored artifact. Each carries a deadline and each is a separate chance to miss one. When a developer sketches the identification module, look for due dates, owners and escalation. If the sketch is a form with a submit button, they have built a survey tool and you will be chasing campuses again within a term.

What goes wrong when you migrate identification and monitoring history?

Two things, and only one is technical. Your evidence lives in three shapes: structured fields in the student information system, scanned documents in a folder tree named by campus, and files in an assessment vendor portal. Joining those to a single student is straightforward for current enrolments and gets harder the further back you go, because students move between campuses, names change, and the folder naming convention changed twice.

The one that catches districts is scope. You cannot migrate only current students, because the students inside an active post exit monitoring window are exactly the ones a reviewer will ask about, and some of them were reclassified three years ago under criteria that have since changed. Their file has to come across with the rule version that applied at the time, not with today's. Decide early how far back the monitoring tail reaches in your state, then treat those cohorts as first class migration scope rather than as archive.

Leave the student information system as the record of truth for enrolment and demographics and build the compliance layer beside it. Nobody needs a second student information system, and a proposal that offers one has misread the problem and will cost several times more.

Why do student information system and assessment feeds break after launch?

The student information system feed rarely stops. It drifts. A campus adds a new enrolment code, a program code is repurposed at the start of a year, a school opens and its identifier does not match the pattern your rules assume. Students then fail to enter the identification queue at all, which is the silent failure, because nothing appears on a screen and nobody raises a ticket about a task that was never created. Alert on the shape of the traffic rather than only on errors: if a campus that normally generates thirty identification tasks a week generates none, that is worth a message on the same day.

Assessment feeds break on the calendar instead. ACCESS for ELLs, ELPAC, TELPAS, NYSESLAT and ELPA21 each deliver results in their own format on their own schedule, and layouts change between administrations more often than anyone expects. A reclassification run against a file with two renamed columns will either fail loudly, which is fine, or match the wrong column and produce decisions that look plausible, which is not. Validate the structure on arrival, refuse anything that does not match the expected shape, and keep last year's parser rather than replacing it so an old file can still be reprocessed.

PowerSchool, Infinite Campus and Skyward are three different data models, and pulling a state assessment file is a fourth. Ask developers which specific system and which specific method they used, not whether they have education data experience. The answer to the second question is always yes.

What happens when post exit monitoring and notification evidence are not covered?

Post exit monitoring fails because it has no owner and no prompt. The fix is structural: reclassification itself creates a monitoring record with a defined end date and scheduled check points that generate tasks to named staff each grading period. Grade and assessment data flows in automatically, so the check is a review of assembled evidence rather than a data gathering exercise a teacher with twenty eight other students will postpone. Students trending downward surface as an alert with a reentry workflow attached, and the end of the window closes the record with a documented outcome. That closed record is the file a reviewer asks for years later.

Notification is an evidence problem rather than a translation problem, and districts consistently misdiagnose it. Most get translation right for their top three languages. What almost none can produce on demand is which notice, which version, which language, which date, sent by which method, for a specific student. Parents must be notified of identification and placement inside defined windows at the start of the year and shortly after a mid year identification, so the date matters as much as the content.

Build notices as versioned templates with language variants, generate them from student data, log the generation event and store the artifact. Record the delivery method, including the campus staff member who handed a printed copy to a caregiver at a conference. Where no approved translation exists for a long tail language, flag it so the office arranges interpreter support in advance rather than discovering the gap during a review.

Should you build custom or configure what you already own?

If you have under roughly 2,000 identified students, your state's exit criteria are a single assessment threshold, and you are not under any agreement or heightened monitoring, buy Ellevation Education and put the money into bilingual staff. It does a genuinely good job on English learner profiles, service plans and teacher facing strategies, and rebuilding that is an expensive way to arrive at the same place.

Before commissioning anything, spend two weeks inside what you own. In most districts the student information system can already carry more of this than it does: custom fields configured years ago and abandoned, alerts nobody enabled, and a reporting tool that stopped being used when the analyst who wrote the queries left. If identification is failing because nobody at a campus knows they own the task, a workflow you configure this month beats a build you commission this year.

Build when two or more of these hold. You have more than roughly 8,000 English learners across many campuses. Your exit criteria are multi criteria with a committee decision rather than a cut score. You are operating under a federal agreement, a consent decree or a state corrective action plan, where the evidence standard is higher and the reporting cadence is set for you. Your reclassification math lives in a workbook that one person maintains. Or your last monitoring visit produced a finding on post exit monitoring, which it probably did, because that is the finding almost everyone gets.

How do hidden costs get into the quote?

Home language count is the first and it is rarely priced honestly. Each additional notice language is not a translation invoice, it is a review workflow, a template variant to keep in step when the notice text changes, and a decision about who signs off that the translation is accurate. Name the languages in scope and price the tail separately from the top three.

Assessment integrations are the second. Each instrument is its own parser with its own annual change risk, and a quote that says assessment integration in the singular has priced one. Get the instruments named, and add an ongoing maintenance line rather than treating them as delivered once.

Historical migration is the third, because the monitoring tail forces you back several years and joining scanned evidence to students at that depth is slow. Fourth is the federal agreement case, where the evidence standard, the reporting cadence and the review meetings all add real hours. Fifth is training across campuses, which lands on your staff rather than the developer's and is why well built systems still fail in year one.

What separates a build that works from one that fails here?

The districts that succeed ship the identification chain first and nothing else: digital home language survey, screening task with a state computed due date and a named owner, placement decision, notification generation with the evidence log. Ten to sixteen weeks, launched before a registration season. The ones that fail attempt identification, reclassification, monitoring, staffing evidence and Title III reporting together and spend a year in requirements while campuses keep using paper.

Insist that rules are versioned data rather than code. Ask a developer how they would represent a reclassification rule that changes in year three while year one decisions must remain defensible under the old rule. If the answer is a formula or a settings page, they have not built compliance software. What you want is dated rule sets, with every decision storing the version it was evaluated under and which evidence satisfied each criterion. That choice is what makes a file survive a review three years later.

Build the reports that make you uncomfortable. Coverage showing which students are receiving service from a teacher without the required certification, and the near miss list of students who met three of four exit criteria, are the two outputs that change decisions. They are also the two that a district is tempted to leave out of scope. Include them.

Settle privacy and ownership in writing before kickoff. State plainly that the district is the data owner under federal student privacy law and any applicable state statute, define what happens to the data if the relationship ends, and take the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the district owns the code from the first commit. Ask what happens to the data at the end before you ask about features.