Do you need a new CDP, or more from the one you have?

Before judging the platform, reconstruct the job it needs to do

A CDP has no inherent business value. Value comes from the use cases it makes possible and the outcomes those use cases influence.

That connection is often lost over time. The implementation becomes the strategy. Teams measure profiles unified, events collected, destinations connected and audiences created. These can indicate progress, but none explains whether the investment is improving acquisition efficiency, conversion, retention, customer experience or operating cost.

Before reviewing vendors or capabilities, rebuild the chain from business objective to technical requirement.

A useful use case should make clear:

• The business objective and metric it is intended to influence
• The customer or operational situation it addresses
• The data, identity and consent conditions it depends on
• The decision or action that needs to occur
• Where that action will be delivered
• The required speed, scale and reliability
• Who will operate it once it is live
• How its impact will be measured

“Create a single customer view” is not a use case. Neither is “real-time personalisation.”

“Recognise an existing customer during a digital session, suppress irrelevant acquisition offers and measure the effect on conversion and media efficiency” is much closer.

Requirements should also be separated into those needed now, those tied to a funded plan and those that are merely plausible in the future. A speculative AI use case should not carry the same weight as a retention journey the business has committed to deliver this year.

Where CDP value usually breaks

It is tempting to reduce the issue to adoption or product fit. In practice, several constraints tend to reinforce each other.

A useful diagnostic is to consider five conditions. This is not a literal formula. It is a reminder that strength in one area cannot fully compensate for failure in another.

The implementation has accumulated debt

CDP implementations often grow organically. New sources, destinations, transformations and use cases are added as the business changes. Organic growth is not inherently a problem. Unmanaged growth is.

Over time, teams create duplicate traits, inconsistent naming, overlapping audiences, brittle integrations and exceptions understood by only one or two people. Logic is repeated across the warehouse, CDP and activation platforms. Documentation falls behind the implementation.

The cost appears in the operating model:

• More engineering effort for routine changes
• Longer lead times to launch use cases
• Manual reconciliation between systems
• Repeated quality assurance for similar workflows
• Failed or delayed activations
• Conflicting definitions of the same customer attribute
• Declining trust among downstream teams

These are real platform costs, but they do not automatically justify replacing the product. Establish whether the implementation can be simplified, then determine whether the platform's architecture makes every new use case disproportionately slow, risky or expensive. Those are different findings and should lead to different decisions.

The people who bought it have left

Software often loses value when its internal owners move on. The original sponsor leaves. Technical knowledge disperses. The business case becomes difficult to find. Nobody inherits responsibility for the CDP as an ongoing capability, so the roadmap turns into a queue of disconnected requests. Users receive little training and gradually develop workarounds.

Gartner reported martech utilisation at 49% in its 2025 Marketing Technology Survey.² This is a martech-wide measure, not a CDP adoption rate, but it illustrates the gap between buying software and embedding it into the way an organisation works.

A replacement can create a temporary burst of attention. It introduces a project, a budget and a deadline. Without a clear product owner, funded roadmap, enablement model and executive sponsor, the new platform is likely to follow the same path as the old one.

The underlying data is not ready

A CDP cannot make unreliable source data trustworthy simply by receiving it. Broken instrumentation, inconsistent identifiers, incomplete consent signals, changing schemas and weak customer definitions will follow the organisation into another platform.

Gartner's April 2025 CDP implementation guidance identifies data readiness, capability fit and cross-functional awareness as critical prework.³ The same checks should precede a decision to move. If the principal constraint is data quality, a migration may consume the people needed to fix it while reproducing the same problems elsewhere.

The last mile is blocking the outcome

Creating a profile or audience is not the result. Value appears only when another system receives the data, a team acts on it and the effect is measured.

A technically successful CDP programme can still stall because content is unavailable, approvals take weeks, consent policy is unclear, a destination cannot use the data as expected, channel teams lack capacity or nobody owns the journey across organisational boundaries.

This is where platform-centric reviews go wrong. They inspect whether the CDP produced the audience but not whether the organisation could turn it into a better customer or commercial outcome. Replacing the CDP does little when the constraint sits after activation.

Platform boundaries are unclear

Customer data capability now spans warehouses, CDPs, CRMs, analytics tools, consent systems and engagement platforms. In many organisations, the boundaries between them were never explicitly designed.

Identity logic may exist in two places. Attributes are computed differently by data and marketing teams. Audiences are recreated across systems. Nobody can say which platform owns consent enforcement or the canonical customer definition.

This matters when considering traditional and composable CDP approaches. The right choice depends on where trusted data lives, which team is equipped to manage it, how much independence business users require, and where identity, governance and activation should sit. Architecture labels alone do not answer those questions.

Requirements have changed, or the vendor has fallen behind them

Not every problem is internal. Vendors merge, reposition and change their product investment. Warehouse-centred architectures have matured. Privacy requirements and channel expectations evolve. AI has introduced useful capabilities, along with a considerable amount of undifferentiated positioning.

The important phrase is fallen behind your requirements. A competitor's new feature is not a reason to move unless it improves an important use case. Equally, a long-standing relationship should not protect an incumbent that cannot support the work the business now needs to do.

Look for evidence:

• Priority use cases remain blocked by structural product limitations
• Credible roadmap commitments have repeatedly slipped
• Reliability or scale problems affect live operations
• Integration constraints create persistent manual work
• Governance, security or regional requirements cannot be met
• The commercial model penalises the way usage is expected to grow
• The vendor's direction no longer aligns with the organisation's architecture

In adjacent marketing automation categories, many baseline capabilities have converged. That does not make every platform equivalent. Deliverability, scale, orchestration, governance, usability, integration and service can still differ materially. But a premium earned through historical product leadership is not automatically justified today.

Do not keep paying for differentiation your organisation does not use.

Challenge the incumbent before going to market

A full market evaluation can be necessary, including where the incumbent ultimately wins. It may provide an independent benchmark, test the available alternatives or give stakeholders confidence that staying is a deliberate decision.

It should not be the first diagnostic step. If a current-state review can answer the question, there is little value in taking several vendors through a lengthy process to discover that the existing platform was capable all along.

1. 01

   Select three to five priority use cases

   Choose work tied to meaningful objectives. Document the data dependencies, operating model, measures and acceptance criteria.

2. 02

   Identify the actual blocker for each one

   Classify the constraint as data, implementation, ownership, process, adjacent technology, commercial model or product capability.

3. 03

   Ask the incumbent to address the suspected gaps

   Invite the vendor's expertise, while keeping validation centred on the use cases and material risks that matter to the buyer.

4. 04

   Put a costed remediation plan beside the case for change

   Compare the work, people and time required to improve with the complete cost of migration, implementation, dual running, validation and retraining.

5. 05

   Take only unresolved material gaps into an evaluation

   Use the verified constraints to shape requirements, demonstrations and any targeted proof of concept.

The current platform is judged with all its historical scars. A new vendor is judged in a clean demonstration.

Correct for that imbalance. Ask the incumbent and challengers to address the same future-state use cases, operating assumptions and total implementation effort.

The decision has more than two outcomes

A review should not force a binary choice between keeping and replacing. Six outcomes are credible when the evidence supports them.

A replacement decision becomes defensible when the organisation can show what is blocked, why the incumbent cannot resolve it, how an alternative has been validated and who will own the new capability once it is implemented.

Until then, dissatisfaction is a reason to investigate, not a business case.