Lessons Learned Building a Unified Data Platform at a Major University

Large-scale data platform projects are complex by nature. Add in multiple departments, years of legacy tooling, and a large organization with competing priorities, and you have a genuinely hard problem to solve.

I have been in the middle of one of those projects, helping lead stakeholder engagement for a unified data platform initiative at a major university. We are still in the thick of it, which means the lessons are fresh. And because we are still building, I want to share what we have learned so far. Not as a post-mortem, but as a mid-journey reflection that might help others avoid the same friction we encountered.

The project involves consolidating multiple Business Intelligence tools used across six departments (HR, Finance, Enrollment Management, Admissions, Financial Aid, and Research) into a single enterprise data platform built on Microsoft Fabric, with Power BI for visualization. We adopted the medallion architecture to organize our data into three layers: Bronze (raw ingestion), Silver (enriched and validated), and Gold (curated for reporting and analytics). In theory, a clean and elegant solution. In practice, we learned that the technology was only a small part of the challenge.

Here is what we would do differently.

1. Start by Understanding the Business Problem, Not the Technology

Before you touch a tool, a platform, or an architecture diagram, get crystal clear on the business problem you are trying to solve. Not the technical problem. The business problem.

What pain are people feeling today? What decisions can they not make because the data is not there? What does "better" actually look like to the people who will use this platform every day?

Once you can articulate that clearly, and once your technical team and your business stakeholders are aligned on the same answer, everything else becomes easier to prioritize. Without that shared understanding, you are building toward different destinations.

This applies whether you are building a unified data platform in higher education, healthcare, or any enterprise environment. The technology is a means to an end. The business problem is the end.

2. Assess Your Current Data Environment Before Planning the Future State

Before we could build something better, we needed a clear picture of where we actually were. That meant doing a proper assessment of the existing data environment: what tools were in place, where the data lived, how it was being used, and what gaps existed.

Skipping or rushing this step is tempting when there is pressure to move fast. But without understanding your current state, you cannot make confident decisions about your future state. You end up discovering things mid-build that should have shaped your foundation.

In a data platform modernization effort, the assessment phase is not optional. It is the foundation that every architecture decision, timeline estimate, and resource allocation depends on.

3. Gather Requirements Before Selecting the Platform

This one stung. In our case, the platform was selected before requirements were fully understood. That meant everything we discovered later had to be worked backward into a solution that was already taking shape. And there was a lot to discover.

Once we engaged stakeholders more deeply, we found:

• Undocumented data sources that had not been accounted for
• Scheduling and refresh requirements that varied across systems
• Different SLAs and integration timelines across departments
• Governance and compliance considerations that had not been included in the original scope

None of these were small edge cases. They were foundational requirements that should have informed the technology decision in the first place.

The lesson: both business requirements and technical requirements need to be fully documented before a platform is even shortlisted. The tool should fit the problem, not the other way around. This is true whether you are evaluating Microsoft Fabric, Databricks, Snowflake, or any other enterprise data platform.

4. Engage Stakeholders Early and Keep Them Engaged

We started engaging key stakeholders later than we should have. By the time we were having the deep conversations about what each department actually needed, we were already well into the build.

This is not about blame. It is a sequencing issue that is easy to fall into when teams are eager to make progress. But the cost of late stakeholder engagement is significant. You do not just slow down. You risk invalidating work that has already been done.

Bring stakeholders in early, keep them in the loop consistently, and make sure every department has a voice in shaping the requirements, not just reviewing what has already been built.

In a university environment, this means engaging not just IT leadership but also the functional owners in HR, Finance, Enrollment, Admissions, Financial Aid, and Research. Each department has its own data culture, its own reporting cadence, and its own definition of what "accurate" means. If you do not surface those differences early, they become blockers later.

5. Have Real Conversations and Get Out of Email

A lot of our early communication happened over email. And email, for all its convenience, is a terrible medium for capturing nuanced requirements. Things get misinterpreted. Assumptions go unchallenged. Important details get buried in threads or lost entirely.

We found that getting on a call or meeting face-to-face (even virtually) surfaced things that emails never would have. When you can talk something through in real time, ask a follow-up question immediately, and see someone's reaction when they hear a proposal, you capture far more than any written exchange.

The assumption that people understand what is expected of them just because it was written in an email is worth challenging early. Clarity is our responsibility as data platform leaders, not theirs as stakeholders.

6. Medallion Architecture: The Right Pattern, but Implementation Matters

We chose the medallion architecture pattern (Bronze, Silver, Gold) to organize data flow through the platform. This is a well-established pattern for enterprise data platforms, and for good reason. It provides clear separation between raw data, validated data, and business-ready data.

But adopting the pattern is the easy part. Implementing it well requires decisions that are harder than they look:

• What qualifies data to move from Bronze to Silver? Validation rules, deduplication logic, and data quality thresholds all need to be defined per source system, not generically.
• Who owns the Gold layer? Is it IT? Is it the business unit? Shared ownership sounds good in theory but creates accountability gaps in practice.
• How do you handle data that does not fit neatly into three layers? Some data sources need intermediate transformations that do not map cleanly to Bronze-Silver-Gold.

The medallion architecture gave us a shared vocabulary and a clear mental model. But the real work was in the implementation details: defining the rules, ownership, and quality gates at each layer.

7. Change Management Is Not an Afterthought

Deploying a new platform is not just a technical event. It is an organizational change. People who have been using familiar tools for years are being asked to learn something new, trust a new system, and change how they work.

That requires a real change management plan: clear communications, structured training, and enough time for people to get comfortable. It also means addressing data governance and security proactively rather than reactively. These are not nice-to-haves. They are the difference between adoption and resistance.

In higher education, this is especially important. Faculty, staff, and administrators have deeply embedded workflows. A unified data platform that technically works but is not adopted is a failed project regardless of how good the architecture looks.

8. Build Agile, Roadmap Thoughtfully, and Get Formal Sign-Offs

Even with the best planning, things change. Requirements evolve. Priorities shift. New information surfaces. An agile approach that iterates in phases, stays flexible, and continuously delivers value keeps the project moving without losing momentum when the unexpected happens.

Pair that with a clear roadmap and formal sign-offs from business stakeholders at each milestone. Do not assume "no news is good news." Get explicit confirmation that what you built matches what was needed before moving to the next phase.

This is especially critical in a data platform modernization initiative where multiple departments are being consolidated. Each department needs to validate that their data, their reports, and their workflows are intact before you move to the next one.

Where We Are Now

As of the publish date of this article, we are still building. The work is not done, and there are more lessons ahead. But sharing this mid-journey felt more useful than waiting for a final chapter that has not been written yet.

If you are embarking on a similar project, whether it is a platform consolidation, a data platform modernization initiative, or any large-scale effort that touches multiple teams and systems, I hope this saves you some of the friction we experienced.

The technology, in the end, is the easy part.

Key Takeaways for Enterprise Data Platform Projects

1. Solve the business problem first. Technology selection comes after requirements, not before.
2. Assess your current state thoroughly. You cannot plan a future state without understanding where you are.
3. Gather requirements before choosing a platform. The tool should fit the problem.
4. Engage stakeholders early and continuously. Late engagement creates rework and resistance.
5. Get on calls, not email threads. Real conversations capture what emails miss.
6. Medallion architecture works, but implementation details matter. Define ownership, quality gates, and transformation rules at each layer.
7. Invest in change management. Adoption is the real success metric, not deployment.
8. Build agile and get formal sign-offs. Iterate, validate, and confirm at every milestone.

FAQ

What is a unified data platform?

A unified data platform is a centralized data architecture that consolidates data from multiple sources, departments, and tools into a single environment for reporting, analytics, and AI. Instead of each department running its own BI tool with its own data, a unified platform creates a single source of truth that the entire organization can work from.

What is medallion architecture?

Medallion architecture is a data organization pattern that structures data into three layers: Bronze (raw, unprocessed data), Silver (cleaned, validated, and enriched data), and Gold (curated, business-ready data for reporting and analytics). It is commonly used in data lakehouses built on platforms like Microsoft Fabric, Databricks, and Oracle AI Data Platform. Read my full guide on medallion architecture.

How long does a data platform modernization project take?

It depends on scope, organizational complexity, and the number of departments being consolidated. A single-department migration might take 3-6 months. A multi-department enterprise data platform initiative like the one described in this article can take 12-24 months or longer, especially when change management, governance, and stakeholder alignment are factored in.

What is the difference between a data platform and a data warehouse?

A data warehouse is a structured repository optimized for reporting and analytics. A unified data platform is broader. It includes the data warehouse but also encompasses data lakes, data pipelines, governance policies, AI/ML capabilities, and visualization tools in a single integrated environment. Modern platforms like Microsoft Fabric, OCI AI Data Platform, Databricks, and Snowflake combine these capabilities.

What are the biggest challenges in building an enterprise data platform?

Based on our experience, the biggest challenges are not technical. They are organizational: late stakeholder engagement, incomplete requirements gathering, resistance to change, unclear data ownership, and misalignment between technical teams and business users. The technology is the easy part. The people and process side is where most projects struggle.

Cory Holmes is an Data & AI Architect, Fractional Chief AI Officer, and Microsoft Certified AI Transformation Leader helping organizations navigate complex technology and AI initiatives. Follow his work at CoryHolmes.com or connect on LinkedIn.

Need help with your data platform or AI strategy? Book a strategy call with Fractional AI Advisors.