Precise strategy.
Measurable results.
From inquiry to outcome.

Walk into almost any public university’s enrollment office and you’ll find the same scene: a financial aid system that doesn’t talk to the student information system, a CRM that can’t pull data from the registrar, and an LMS that exists in its own sealed universe. Staff spend hours manually exporting spreadsheets, copy-pasting data between platforms, and reconciling records that should have been connected automatically years ago.

This is not a technology problem. The APIs exist. The integrations are buildable. The data is there.

This is a leadership problem — and it is about to become a very expensive one.

In my thirty years working inside public higher education — including directing admissions operations across 25 CUNY campuses — I watched the same dynamic play out repeatedly. On one side, IT departments that understood infrastructure but had no meaningful grasp of how enrollment, advising, financial aid, and student success actually function together. On the other, academic and enrollment leaders who could articulate the student experience fluently but couldn’t speak technology’s language well enough to demand the right solutions. In the middle: students falling through the cracks between systems that were never designed to find them.

The result is institutions spending millions on platforms — Salesforce, Banner, Slate, EAB Navigate, Brightspace — that operate as expensive silos rather than as an integrated ecosystem. But the cost goes deeper than software licenses.

Consider what actually happens across a typical university on any given week. The enrollment office pulls its own spreadsheet. Financial aid pulls theirs. The registrar pulls another. The advising team builds its own report. Each department is analyzing the same students through a different lens, on a different schedule, with data that was never designed to speak to anyone else’s. Nobody sees the full picture. Nobody knows how much time is being collectively wasted. Add it up across departments, across campuses, across a system like CUNY — and you are looking at millions of dollars in redundant labor annually, in institutions where budgets are already stretched to the breaking point.

This was always inefficient. In a world where artificial intelligence is now being asked to help institutions understand their students, it has become a structural liability.

Here is the problem few people are talking about: AI cannot reconcile data it doesn’t know is equivalent. If credit hours are labeled one thing in the advising database and something slightly different in the SIS, an AI model asked to analyze student progression will fail — not because the AI is inadequate, but because the data foundation it is working from was never integrated to begin with. Garbage in, garbage out has always been true. With AI, the consequences are faster and more consequential.

The fix is not primarily technical. It requires leadership that understands both worlds — what the data should do for students and what it actually takes to make systems communicate. And here is the uncomfortable truth: this problem is not unique to higher education. In the private sector too, API connections between systems often go unbuilt — not because the technology doesn’t exist, but because nobody in the room knew to ask for them. The gap between the people who understand the business problem and the people who can build the technical solution exists everywhere. Higher education just has less margin to absorb the consequences.

Until universities close that gap — hiring and empowering leaders who can speak both languages, demanding integration over the next shiny platform purchase, and building data infrastructure that serves the whole institution rather than each department’s individual spreadsheet — no amount of AI investment will deliver on its promise.

The tools are not the issue. The leadership is.

In a large public university system, transfer credit evaluation is one of the most labor-intensive processes in academic administration. Every time a student arrives with credits from another institution, someone has to determine what those credits are worth — which courses they satisfy, which requirements they fulfill, whether they transfer at all. At the City University of New York, staff at each campus spent years — sometimes decades — building equivalency rules in CUNYFirst, the university’s Oracle/PeopleSoft-based student information system. Lehman College alone had built around 50,000 rules. Across the full system, the collective inventory ran into the hundreds of thousands. Each rule took two to five minutes to build by hand.

Nobody questioned this. It was just how it worked.

When I was directing admissions operations at CUNY’s Borough of Manhattan Community College, my team was responsible for transfer credit evaluation — an unusual arrangement, but one that gave me unusual visibility into the data. We had built roughly 2,000 rules. Other campuses had built far more, over far longer periods of time. The collective labor represented by hundreds of thousands of rules was staggering.

What I noticed was that all of those rules — every equivalency built by every campus over years of painstaking work — were sitting in local CUNYFirst reports. Each campus could see its own rules. Nobody could see anyone else’s. I asked, repeatedly, why the reports weren’t set to a shared type that all campuses could access. I never got a satisfying answer. Probably because nobody had ever asked before.

So I looked at the report coding and changed it myself.

Once the reports were global, I ran them for every CUNY campus. My data team linked the results in Microsoft Access to build what I started calling the Rosetta Stone: a master equivalency map across the entire system. The logic was straightforward once you could see it. If Lehman had established that a course at an external institution was equivalent to one of their courses, and BMCC had established that same Lehman course was equivalent to one of ours, we could derive the external-to-BMCC equivalency without building it from scratch. Transitivity. Basic relational logic. Invisible to everyone because nobody had ever connected the datasets.

Then I went to the IT team at CUNY Central and told them I needed the derived rules mass-imported into CUNYFirst across all campuses simultaneously. They said that wasn’t possible. I told them it had to be. It was.

But we weren’t done. Before any rule went live, it had to be verified. We de-duped the derived dataset and posted the final rules on a shared document, inviting department chairs — particularly in computer science and accounting, where the rule volumes were highest and the objections were loudest — to flag anything they thought might be wrong.

Some of them had concerns. We listened carefully. We also pointed out, gently, that Lehman College — one of CUNY’s four-year senior colleges — had already validated many of the same equivalencies and found them sound. The fact that we were a community college making this argument did not, it must be said, land with universal enthusiasm.

But the rules held. The import ran. The process that had consumed years of collective staff time across the system was effectively complete.

The lesson isn’t about CUNYFirst or Access or report types. It’s about what becomes possible when someone asks the question nobody thought to ask — why are these systems designed not to talk to each other? — and then does something about it without waiting for permission.

The data was always there. The connection was always possible. It just needed someone to see it.