Most enterprise AI and migration failures trace back to poorly designed or degraded data models, not the platforms organizations blame for underperformance.
Mike Zimmerman, Fractional CTO and founder of Blue Sprout Consulting, says governance must move upstream into transactional systems and that traditional dashboards are giving way to AI-driven, query-first analytics.
He points to AI agents as force multipliers for disciplined teams, capable of accelerating migrations and acting as collaborative programming partners while maintaining auditability.
When an AI project fails, the postmortem almost always points to the platform. The migration went wrong. The cloud provider fell short. The tooling could not handle the workload. But strip those explanations back far enough, and the real cause is nearly always the same: a data model that was flawed from the start or one that degraded over years of undisciplined changes.
Mike Zimmerman is the Founder and Principal of Blue Sprout Consulting, where he serves as a Fractional CTO and Technology & Data Strategy Advisor to growth-stage, PE-backed, and regulated organizations. With more than 15 years as a former founder and CTO who built and scaled digital products, data platforms, and engineering teams across multiple industries, Zimmerman brings a practitioner's lens to the challenges of data readiness and AI adoption.
"Most AI and data project failures aren't about the platform. They're about flawed data models and overlooked governance. If the model is wrong or degraded, the tooling just exposes the problem faster," Zimmerman says.
The problem, he explains, is structural and decades in the making. Rigorous domain-driven design requires significant upfront thought, discipline in object-oriented concepts, and experience that most programs simply do not teach. Without those foundations, models accumulate what Zimmerman calls hidden tech debt.
A slow corruption: Even well-designed models degrade as teams change. "A model might start out really good. But over time, new people take it over, maybe they're not as disciplined, and they start shoving things into columns that were never intended for that. Code inside the database. All kinds of stuff you're not supposed to do, but you see it over and over across enterprises."
The wrong store for the job: Choosing the right type of data store matters as much as the model itself, Zimmerman continues. "Historically, the default is to create a relational model. But more time needs to be spent on what is the right tool for storing the type of data you actually have. And then putting in the right protections so your data stays within the bounds you originally intended."
Lift, shift, then fix: For teams migrating to PostgreSQL, Zimmerman sees the lift-and-shift approach as a valid first step, not a final answer. A recent Oracle-to-Postgres engagement revealed dozens of subtle issues, from floating-point join performance to date-handling differences, that required extensive code changes before the system could perform. "Get it running in Postgres first. Then from there, you can make the model better."
That pragmatism extends to how Zimmerman thinks about the separation between transactional and analytical systems. He resists the growing pressure to unify them for AI access, noting that the query patterns are fundamentally different and forcing convergence risks reintroducing the same modeling problems at larger scale.
Dashboards are dead: The more consequential shift, in his view, is the collapse of traditional reporting. Organizations still invest in dashboard-first thinking when the real need has moved to query-driven, AI-powered analytics. "I don't need a dashboard. I need answers to my questions. I want to ask questions, then dive deeper and ask more. AI and agents have absolutely flown by what historical dashboards and reporting solutions provided."
Governance, moved upstream: Zimmerman argues that data governance cannot remain an analytical-side concern. The same discipline needs to apply to transactional systems, where data quality problems originate. "If you're going to keep your data clean, you want to move that as far upstream as you can. It just makes everything easier downstream."
Where AI enters the picture is as a force multiplier for disciplined teams. Zimmerman recently built an entire SQL Server-to-Postgres migration CLI using Claude, complete with full auditing, transaction awareness, and repeatability. Halfway through, a major structural issue surfaced that would have required days of manual rework. "I told Claude what the issue was, and it went and updated 27 different files to fix the problem. It was done in thirty minutes."
The experience reminds him of extreme programming, the pair-programming methodology where two developers build together to produce better designs in less time. "When I'm working with Claude, I feel like I am fully doing extreme programming. My partner is an AI agent. It's only taking one person instead of two." But the lesson cuts both ways. AI amplifies whatever it finds. When the underlying model is sound and governance is in place, an agent can accelerate work by orders of magnitude. When those foundations are missing, it accelerates the mess.
