Data catalog implementation plan: a step-by-step guide for enterprises

At Murdio, we’ve helped large enterprises implement data catalogs across financial services, retail, energy, and manufacturing – and the pattern is consistent. Most programs don’t fail because of the technology. They fail because the organization wasn’t ready for what a data catalog actually demands: defined ownership, a scoped first use case, and executive commitment that survives the first difficult quarter.

This guide is the implementation blueprint we use with clients – shaped by programs that stalled, scope that ballooned overnight, and the hard lesson that loading metadata into a catalog is the easy part. Getting people to own, maintain, and trust it is where the real work happens.

Below you’ll find the full enterprise data catalog implementation journey: prerequisites that must be in place before you go live, four phases from scoping to enterprise rollout, the team and roles you’ll need, and the failure patterns that are entirely avoidable – once you know what to look for.

Key takeaways:

• Most data catalog implementations fail for organizational reasons, not technical ones.
• Your first use case determines whether the program builds momentum or quietly dies.
• A working pilot in one domain is worth more than an ambitious rollout that never reaches production.
• If you’ve already selected Collibra, the phases below apply – but the specifics differ significantly. Our dedicated Collibra implementation guide covers the full blueprint.

Why data catalog implementations fail

Before you plan a single phase, it’s worth understanding what actually kills these programs. In our experience, the failure points are remarkably consistent – and almost none of them are technical.

• Starting with the tool, not the problem. The most common mistake we see: an organization selects a platform, signs the contract, and only then asks what problem they’re solving. A data catalog is an answer to a question. If the question isn’t defined – “which datasets feed our risk reporting?” or “who owns our customer data across domains?” – the catalog becomes a very expensive metadata repository that nobody uses.
• No data ownership before go-live. A catalog without owners is a catalog that goes stale within months. If your organization hasn’t defined who is accountable for which data – before the platform launches – you’ll spend the first year chasing people to fill in fields rather than governing anything. Ownership needs to be established as a governance decision, not delegated to a tool.
• Trying to catalog everything at once. Scope creep at kickoff is one of the most reliable ways to ensure a program never reaches production. When every domain head wants their data in the first release, and every stakeholder adds requirements to the backlog, the pilot becomes a full enterprise rollout before the first sprint ends. Start with one domain. Prove value. Expand.
• Underestimating change management. Data stewardship means changing how people work. It means asking a business analyst to document assets, an engineer to validate lineage, and a domain lead to formally own data quality. This is organizational change, not a software deployment. Programs that treat it as the latter consistently underdeliver on adoption.
• No executive sponsor with real accountability. Data governance projects without a C-level champion – someone whose performance is tied to outcomes, not just someone who “supports the initiative” – always drift. When prioritization conflicts arise (and they will), a sponsor without skin in the game will consistently lose to other business priorities.

“The most expensive mistake we see is buying a platform before defining a problem. We’ve inherited programs where the tool was live for six months and nobody could answer the question: what exactly are we governing, and for whom? Getting that answer first saves you a complete restart.”

Łukasz Banaszewski, Co-founder, Murdio

Recognizing any of these? If your program is already in motion and something feels off – or you’re about to start and want to pressure-test your approach – we’re happy to talk it through. Let’s have a conversation →

Prerequisites – what must be in place before you implement

A data catalog doesn’t create governance. It operationalizes governance that already exists. This distinction matters more than most organizations realize when they start scoping an implementation.

Before your program moves into platform selection or configuration, the following should be in place – at least in a working, imperfect form. Waiting for perfection is its own failure mode. But going live without any of these is a reliable path to a stalled program.

• At least one clearly defined use case tied to a business pain. Not “improve data discoverability.” Something specific: “Our risk team can’t trace which source systems feed the regulatory report” or “We don’t know what personal data we hold and where.” The use case defines what you build first and what success looks like.
• An executive sponsor who is accountable for outcomes. Not a supporter – an owner. Someone who will defend the budget, resolve cross-departmental conflicts, and whose priorities include making this succeed.
• Data domains mapped, even roughly. You don’t need a perfect domain model. You need enough clarity to know which domain owns the first use case and who leads it.
• A data ownership model started. Who is accountable for which data? This doesn’t need to be fully operationalized, but the conversation must have happened and initial assignments made before the catalog goes live.
• A basic data governance policy or framework. Even a lightweight one. The catalog will enforce rules and workflows – those need to reflect real governance decisions, not be invented inside the tool configuration.
• IT infrastructure readiness assessed. Cloud vs. on-premise decision made. SSO and access management approach defined. The integration landscape is understood at a high level.
• An internal project lead assigned. One person who owns the program day-to-day, bridges business and IT, and is accountable for keeping it moving. This role is often underestimated and understaffed.

The 4 phases of a data catalog implementation

Phase 1: Scoping & business case (Weeks 1-6)

The goal of Phase 1 is not to build anything. It’s to establish the conditions under which the rest of the program won’t fail.

This phase ends with three things agreed and documented: what you’re solving, who is accountable for solving it, and what success looks like at the end of the pilot. Everything else – platform selection, team staffing, configuration – depends on getting these right.

Choose your first use case

The best first use case sits at the intersection of three things: a business pain that someone in leadership already feels, data your organization controls and can access, and stakeholders who are willing to engage. In practice, the strongest candidates tend to be regulatory lineage, critical KPI documentation, or data domain ownership modeling for a high-visibility reporting area. The wrong choice is “implement the catalog for all our data.” That’s a program, not a use case.

Build the business case

Connect the use case to outcomes that leadership cares about: audit exposure reduced, reporting cycle shortened, regulatory risk addressed. A business case framed around data quality abstractions rarely survives budget season. One framed around a specific regulatory deadline or a recurring data incident has a much better chance. If you need guidance on cost benchmarking, our data catalog pricing guide covers what enterprise implementations typically cost.

Secure executive buy-in

Buy-in doesn’t come from communicating better. It comes from solving a problem the business already feels. If your sponsor doesn’t personally experience the pain your first use case addresses, find a use case that connects to someone who does.

Define what success looks like

Before moving forward, agree on a “Phase 1 done” definition. Something concrete: “Pilot domain cataloged, ownership assigned, lineage validated for the regulatory report, core team trained.” Vague success criteria guarantee scope disputes later.

Phase 2: Platform selection & team setup (Weeks 4-10)

Platform selection should follow use case definition, not precede it. The right tool for your program depends entirely on what you’re solving, at what scale, and with what internal capability. Organizations that select a platform before defining a use case routinely discover – six months into configuration – that the tool doesn’t fit the governance model they actually need.

How to evaluate platforms

The criteria that matter most in an enterprise context:

Criterion	What to evaluate
Use case fit	Does the platform support your first use case out of the box?
Metadata model flexibility	Can it represent your data domains without heavy customization?
Integration ecosystem	Does it connect to your existing stack (cloud, BI, pipelines)?
Governance workflow support	Can it enforce ownership, certification, and approval processes?
Scalability	Can it handle your data volume and user count at enterprise scale?
Total cost of ownership	License + implementation + ongoing maintenance
Vendor support & partner ecosystem	Active development, documentation quality, available expertise

For enterprises operating under strict regulatory requirements – DORA, BCBS 239, GDPR – pay particular attention to lineage depth, auditability, and workflow enforcement capabilities. Not all platforms are equal here.

Build your implementation team

This is the point where many programs are already understaffed before they start. A data catalog implementation is not an IT project with governance involvement. It’s a governance program that requires technical delivery. The team needs to reflect that.

Role	Responsibility	When they join
Executive Sponsor	Business accountability, budget, escalation	Phase 1
Data Governance Lead	Strategy, policy, stewardship model	Phase 1
Project Manager	Timeline, coordination, stakeholder communication	Phase 1
Data Catalog Admin (IT)	Platform setup, configuration, integrations	Phase 2
Data Stewards (business)	Asset ownership, metadata curation, workflow participation	Phase 2-3
Domain Data Owners	Accountability for data quality within a domain	Phase 3
External Implementation Partner	Accelerate delivery, fill expertise gaps, de-risk the program	Phase 2 (optional but recommended)

When to bring in external expertise

Internal teams are rarely self-sufficient for a first enterprise data catalog implementation. The combination of platform-specific technical knowledge, governance design experience, and change management capability is difficult to assemble internally – especially if the team is running the program alongside their day job.

An external partner adds most value when engaged early: shaping the governance model, configuring the platform correctly from the start, and transferring knowledge so your internal team becomes self-sufficient over time. The cost of fixing a flawed implementation six months in is significantly higher than getting the foundations right upfront.

Not sure what your implementation actually needs? Tell us where you are – use case defined or still fuzzy, platform chosen or still evaluating – and we’ll help you figure out what the right next step looks like. Talk to a Murdio expert →

Phase 3: Pilot deployment (Weeks 8-20)

The pilot is where the program either builds credibility or loses it. A successful pilot doesn’t mean perfect – it means demonstrable value in a contained scope, delivered within a timeframe that keeps stakeholders engaged.

The rule that governs everything in this phase: one domain, one use case, high visibility. Resist every pressure to expand scope before the pilot closes.

Configure the catalog for your first use case

At this stage, configure only what your pilot use case requires. This means:

• Catalog structure and asset types relevant to the pilot domain
• Initial metadata ingestion – high-value datasets only, not everything available
• Ownership assignments for assets in scope
• Basic governance workflows: ownership assignment, certification, glossary term lifecycle
• Access controls and user roles for the pilot team

Over-ingesting at this stage is one of the most common pilot mistakes. A catalog populated with thousands of poorly documented, unowned assets on day one destroys user trust immediately. Start small. Start clean.

Engage stewards early and hands-on

Training is not enough. Data stewards need to work inside the catalog during the pilot – editing assets, participating in workflows, flagging issues – not learn about it in a slide deck. The sooner stewards experience the tool as part of their actual work, the faster adoption takes root.

Run working sessions, not presentations. Sit stewards in front of real assets from their domain and walk through real governance tasks. Collect feedback actively. The pilot is your best opportunity to identify friction before it becomes an adoption blocker at scale.

“A pilot that runs for four months and delivers nothing measurable isn’t a pilot – it’s a proof of concept that lost its scope. We always say: if you can’t point to one concrete outcome after eight weeks, something went wrong in Phase 1, not Phase 3.”

Łukasz Banaszewski, Co-founder, Murdio

Measure pilot success

Before the pilot closes, validate against the “done” definition agreed in Phase 1. Additionally, establish baseline measurements that will track progress through Phase 4:

• Asset coverage: what percentage of the target domain is documented
• Ownership coverage: what percentage of assets have an assigned owner
• Steward engagement: are governance tasks being completed, or stacking up
• Time-to-find-data: can analysts locate a trusted dataset faster than before

If the pilot can’t demonstrate measurable value in its domain, scaling to the enterprise will not fix the underlying problem – it will amplify it.

Pilot stalling or not delivering the value you expected? We’ve seen most failure patterns before – and most of them are fixable earlier than you’d think. Let’s talk about what’s happening →

Phase 4: Enterprise rollout & adoption (Months 6-18+)

When the pilot delivers, the conversation changes. Stakeholders who were skeptical start asking when their domain gets onboarded. Leadership wants a timeline. The program shifts from proving value to scaling it.

This phase is where governance either becomes part of how the organization operates – or gets deprioritized as the next initiative takes the spotlight. The difference usually comes down to how deliberately adoption is managed.

Sequence domain expansion carefully

Don’t onboard every domain simultaneously. Prioritize based on business impact and stakeholder readiness. A domain with engaged ownership and a clear use case will deliver faster than one with contested accountability and low motivation – regardless of how strategically important the data is.

For each new domain, repeat the core pilot pattern: define the use case, assign ownership, configure what’s needed, train stewards with hands-on sessions. The difference from Phase 3 is that your team now has a repeatable playbook and a working reference implementation to point to.

Invest in automation – at the right time

As the catalog scales, manual metadata maintenance becomes unsustainable. This is the point to invest in automation:

• Automated metadata ingestion from source systems
• Scheduled freshness checks and lineage updates
• Auto-tagging for PII and sensitive data classifications
• Bulk updates via API for large-scale changes
• Workflow triggers connected to upstream data pipeline events

The critical qualifier: automate after the governance model is stable. Automating ingestion into an unstable catalog structure means re-ingesting everything every time the model changes.

Make adoption visible

Adoption doesn’t sustain itself. Build dashboards that make governance progress visible to leadership and domain teams: ownership coverage by domain, glossary adoption rates, certification status, data quality trends. When a domain lead can see their team’s progress – and compare it to others – governance becomes competitive in the best way.

Treat the catalog as a living system

A data catalog is not a project with an end date. It’s an operational capability that needs ongoing investment: new domains onboarded, metadata kept fresh, workflows refined as processes change, and the governance model evolved as the organization matures.

Programs that treat Phase 4 as the finish line typically find their catalog slowly degrading – assets going stale, ownership lapsing, stewards disengaging. The organizations that sustain value are the ones that build continuous improvement into the operating model from the start. For a deeper look at what drives long-term governance adoption, see our guide on data governance adoption.

How to measure data catalog implementation success

Measuring success in a data catalog program requires moving beyond technical milestones – “platform configured,” “ingestion running” – and tracking whether governance is actually happening. The metrics below give you visibility at each stage of the implementation.

Metric	What it measures	Target benchmark
Catalog adoption rate	% of target users logging in monthly	>60% at 6 months post-launch
Asset coverage	% of target data assets documented in the catalog	>70% of priority domain at pilot close
Data ownership coverage	% of assets with an assigned owner	>80% across active domains
Time-to-find-data	Avg. time for an analyst to locate a trusted dataset	Measurable reduction vs. pre-catalog baseline
Steward task completion rate	% of governance tasks completed within SLA	>75%
Glossary adoption	% of core business terms linked to cataloged assets	>50% of core business glossary

A few things worth noting on how to use these:

• Establish baselines before go-live. Metrics like time-to-find-data are only meaningful if you have a pre-implementation reference point to compare against.
• Track steward engagement separately from passive adoption. A user who logs in once a month is not the same as a steward completing certification workflows on schedule. Both matter, but they tell different stories.
• Review metrics with domain leads, not just the governance team. When business stakeholders see their domain’s numbers, ownership of the outcomes – not just the data – tends to follow.

Implementing Collibra specifically?

If you’ve selected Collibra as your platform, the four phases above apply – but the implementation specifics differ significantly from other tools. Collibra’s metamodel design, workflow engine, and connector architecture require dedicated expertise to get right, and the consequences of early configuration mistakes compound quickly as the program scales.

Our in-depth guide covers the full Collibra implementation blueprint: phased rollout, operating model design, common stall patterns, and how to avoid them: A proven data governance Collibra implementation plan →

FAQ