This article opens a series on what it takes to build a trusted data foundation for modern higher ed. Across the series, we will look at why application modernization alone does not solve campus data problems, how shared definitions and point-in-time history support better reporting, why cross-system questions need a cross-system foundation, and what governed data means for dashboards, data culture, and safer AI adoption.

 

Jump to the part you are probably living right now

• When the new system works, why do the old data arguments remain?
• Who decides how your institution reaches its data?
• Why do correct systems still produce conflicting answers?
• When does a better dashboard stay trapped inside one system?
• What should your institution own apart from any one application?
• How does that foundation reach the people making decisions?
• What belongs in every modernization plan?

When the new system works, why do the old data arguments remain?

The migration is finished. The new system is live. The interface is cleaner.

The project team has earned the right to be tired. Then a cabinet member asks a practical question: are the students showing enrollment risk the same students showing weak course activity and unresolved financial aid?

The trouble starts when the answer has to cross system lines. Each system holds part of the answer.

The meeting moves from the student population to the data trail. Someone exports a file. Someone else asks which population was frozen after census. The question has not changed. The institution’s path to answering it has.

A school can modernize every major application and still weaken control of its institutional data. Application modernization changes where work happens. It does not automatically create a durable data strategy.

Who decides how your institution reaches its data?

Institutions have good reasons to choose different deployment models. Some want SaaS because it reduces infrastructure burden. Others prefer on-prem because local control, direct access, and established reporting practices matter. Both choices can make sense.

The data risk appears when the application decision gets treated as the data decision.

In a locally managed environment, teams usually have more direct paths to the underlying data. Those paths still need governance, documentation, security, and staff expertise. They also give the institution room to shape data for reporting.

SaaS changes the route. Data access usually moves through vendor-defined APIs, exports, reporting modules, and security models. The institution owns the data as a matter of policy and contract. Day to day, the usable path depends on what the vendor supports.

That path shapes what data can be retrieved, how much detail comes through, and how quickly a change becomes available. A department report may work fine. A cross-system answer before a board meeting may not.

Why do correct systems still produce conflicting answers?

Access is only the first problem. Even reachable data does not arrive with shared meaning.

Every major campus system has a domain. The SIS manages student records. The LMS captures learning activity. The CRM supports admissions. Finance tracks spending. Advising records outreach.

Each system describes the institution through the work it supports. A student can be active in the SIS, quiet in the LMS, unresolved in financial aid, and contacted by advising. Each statement can be accurate. Together, they require interpretation.

The same problem appears in institutional metrics. “Enrolled” before add/drop does not carry the same meaning as enrolled on census day. “Active” in a student system does not automatically match the population finance uses for revenue planning.

Most reporting fights start with domain-specific answers that were never reconciled into an institutional answer. Each office brings a defensible number. The meeting stalls because no one can show which number should guide the decision.

When does a better dashboard stay trapped inside one system?

Vendor dashboards help teams manage local work. A CRM dashboard can show funnel movement. An LMS dashboard can show course activity. A finance dashboard can show spending.

Those views earn their place when the question lives inside the same domain. The issue appears when a local answer gets used for an institutional decision.

A CRM view can show who accepted an offer and paid a deposit. It does not show which of those students registered late, missed orientation, stopped logging into the LMS, or needed aid follow-up.

The dashboard did its job. The institution needed a different kind of answer.

The campus gains cleaner local reporting while the larger picture stays scattered across application boundaries. People still stitch the story together later.

What should your institution own apart from any one application?

Schools need a neutral data foundation apart from any one operational application. Its job is practical: bring data together, preserve important history, apply shared definitions, and make the result usable across departments.

Storage alone will not solve this. Five systems dumped into one place can become five problems with a shared address. The foundation has to make the data easier to use and trust.

That means preserving moments that matter: census day, add/drop, fiscal close, accreditation periods, board reporting cycles. It also means giving definitions a stable home: enrolled, active, retained, registered, financially cleared, at risk.

Those definitions carry weight. When every office rebuilds them from its own system, the same word becomes several numbers.

Applications will keep changing. Contracts renew. Vendors adjust roadmaps. Systems move through replacement cycles. The institution still needs a durable place for its history, definitions, and cross-system relationships.

How does that foundation reach the people making decisions?

People still need reports, dashboards, scheduled outputs, embedded views, and role-based access. They need answers near the work.

A provost needs academic trends and student progress. An advisor needs student-level context before outreach. Finance needs enrollment context around budget decisions. IR needs repeatable definitions and a reliable historical record. Cabinet needs enough context to make a decision without turning every meeting into reconciliation.

Those different views should come from the same underlying foundation. The format changes by role. The meaning should not.

That is why delivery matters. Reports, dashboards, scheduled outputs, and embedded views decide whether a data foundation becomes useful outside the technical team.

What belongs in every modernization plan?

Every modernization plan should include one uncomfortable question early enough to matter:

Will this strengthen our institutional data strategy, or will it create another place where data gets trapped?

Then make it specific. Can we retrieve the data at the level of detail we need? Can we preserve history when the source system focuses on the current state? Can we combine this data with other systems without a new manual process? Can we define core metrics once and use them across departments? Can the reporting strategy survive the next system change?

Weak answers do not mean the application project is wrong. They mean the application project carries a data risk.

SaaS can be the right move. On-prem can be the right move. Vendor dashboards can be useful. Department- level reports can serve real needs. None of those choices replaces an institutional data strategy.

The institutions that handle modernization best will keep control of the place where history, definitions, and cross-system questions come together. Applications can change. Their data strategy stays theirs.

 

Coming Next in the Series

Article	Topic	What Readers Can Expect
2	Higher Ed Does Not Have a Data Problem. It Has a Trust Problem.	A closer look at why more data does not automatically create more confidence, and how shared definitions, governance, and trusted reporting help campus teams work from the same answer.
3	Stop Rebuilding History Every Reporting Season	A practical look at point-in-time reporting for census, IPEDS, accreditation, audits, and trend analysis, especially when teams need to explain what changed and when.
4	Cross-System Questions Require a Cross-System Data Foundation	Why student success, enrollment, finance, and operations questions cannot be answered one system at a time, and what it takes to connect the pieces responsibly.
5	Data Culture Is Not Built by Dashboards Alone	How institutions move from access to use, with trusted data, role-based delivery, literacy, and reporting people can act on in their daily work.
6	AI Readiness Starts Before the Prompt	Why safer AI starts with governed data, historical context, clear permissions, and human judgment before anyone asks the first question.