# CDP Survivorship Rules: How to Reconcile CRM, Product, and Support Data Without Polluting the Customer Profile

May 19, 2026

By Oleksiy Kalinichenko

Unified profiles become unreliable when enterprises merge attributes from multiple systems without explicit survivorship logic, precedence rules, and operational review.

This article explains how **CDP survivorship rules** shape Customer 360 quality once CRM, support, commerce, and product data all feed the same profile. It focuses on attribute precedence, conflict handling, recency logic, and governance patterns that keep activation and reporting trustworthy.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260519-cdp-survivorship-rules-between-crm-and-product-data "Summarize this page with ChatGPT")[](https://claude.ai/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260519-cdp-survivorship-rules-between-crm-and-product-data "Summarize this page with Claude")[](https://www.google.com/search?udm=50&q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260519-cdp-survivorship-rules-between-crm-and-product-data "Summarize this page with Gemini")[](https://x.com/i/grok?text=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260519-cdp-survivorship-rules-between-crm-and-product-data "Summarize this page with Grok")[](https://www.perplexity.ai/search/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260519-cdp-survivorship-rules-between-crm-and-product-data "Summarize this page with Perplexity")

![Blog: CDP Survivorship Rules: How to Reconcile CRM, Product, and Support Data Without Polluting the Customer Profile](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20260519-cdp-survivorship-rules-between-crm-and-product-data--cover)

A unified customer profile is only as useful as the logic used to assemble it.

Many enterprises invest heavily in identity resolution, match rules, and profile stitching. That work matters. But once records from CRM, support, commerce, product analytics, and web interactions have been linked to the same person or account, a harder question appears: **which value should the profile keep when systems disagree?**

That is where **CDP survivorship rules** become essential.

Survivorship rules define how a Customer 360 profile chooses, preserves, updates, or flags attributes when multiple sources contribute data for the same field. Without them, a unified profile can become a container for unresolved conflicts rather than a trusted operational asset. Teams may believe they have a single customer view, while in practice they have a blended record with unclear ownership and inconsistent logic.

[Conflicting profile fields weakening identity trust?Run Health Check→](/cdp-health-check?context=identity#run)

For enterprise digital platforms, this problem is not academic. Profile values drive segmentation, personalization, lifecycle reporting, service workflows, audience exports, and downstream activation. If the email owner, lifecycle stage, geography, consent status, account tier, or product usage flags are wrong, every dependent process becomes less reliable.

The goal is not to force every field into one universal rule. The goal is to establish governed, field-level logic that reflects business meaning, system responsibility, and operational risk.

### Why identity resolution is not enough once attributes conflict

Identity resolution answers a matching question: do these records likely refer to the same customer, household, user, or account?

Survivorship answers an assembly question: now that the records are connected, what should the unified profile actually say?

Those are related but distinct decisions.

A common implementation mistake is to treat profile assembly as an automatic byproduct of identity stitching. In reality, matching records can increase ambiguity if the organization has not defined how conflicting attributes are resolved. When four systems contribute values for `country`, `customer_status`, or `job_title`, the identity graph may successfully link the records while still leaving the profile semantically inconsistent.

Consider a simple example:

*   CRM says the contact's title is `VP of Operations`
*   Support says `Director of Operations`
*   A web form says `Operations Lead`
*   Product analytics has no title at all

The person may indeed be the same individual. Identity resolution can be correct. But the resulting profile is still not trustworthy until there is a rule for which title survives, under what conditions, and whether some values should be flagged rather than overwritten.

This is why Customer 360 programs need to move beyond merge-first thinking. Unification without [survivorship governance](/services/identity-resolution-strategy) often produces profiles that look complete but behave unpredictably.

### Common survivorship failure modes across CRM, support, commerce, and web events

Most survivorship issues do not come from exotic edge cases. They usually come from ordinary enterprise data flows where different systems were designed for different operational purposes.

Here are several common failure modes.

**1\. Last-write-wins applied too broadly**

Recency is useful, but it is not universally correct. A recent web form submission should not automatically overwrite a validated CRM field if the form is low-friction and prone to free-text variation. Likewise, a recent support ticket should not necessarily redefine account segment or revenue tier.

**2\. High-volume event sources overwhelming mastered systems**

Product and web events often generate more frequent updates than CRM or commerce systems. If event-driven pipelines are allowed to overwrite profile attributes simply because they are newer, operational systems can lose authority over fields they are meant to own.

**3\. Null and partial values degrading profile quality**

Some pipelines unintentionally treat blank values as legitimate updates. A support sync that sends an empty phone field can erase a previously verified CRM number if null handling is not explicit.

**4\. Field ownership not aligned to business meaning**

Different systems can be authoritative for different facts. Commerce may be the best source for `last_purchase_date`, while CRM may own `account_owner`, and product telemetry may be best for `last_active_date`. Problems arise when one generic merge strategy is applied to all fields regardless of domain ownership.

**5\. Confusing observed behavior with declared attributes**

Product telemetry may imply that a user is highly engaged, but that does not mean the telemetry system should set lifecycle stage, customer tier, or contractual status. Inferred signals and declared states should not be treated interchangeably.

**6\. Hidden conflicts left unresolved**

Some implementations quietly choose a winning value without preserving source lineage, confidence, or previous values. That makes it difficult for downstream users to understand why a profile changed, whether the change was expected, and how to troubleshoot anomalies.

**7\. One-time rule design with no operational follow-through**

Survivorship is not a set-and-forget configuration exercise. Source systems change, new channels appear, schemas evolve, and business definitions shift. Rules that were reasonable at launch can become harmful over time if they are not reviewed.

![](https://res.cloudinary.com/dywr7uhyq/image/upload/w_640,f_avif,q_auto:good/v1/cta--cdphc--mid--identity--compact)

### See where identity logic breaks under source conflict

Assess how identity resolution, attribute precedence, and profile governance hold up across CRM, product, and support data.

*   Audit source precedence
*   Spot overwrite risks
*   Check profile trust

[Start identity Health Check→](/cdp-health-check?context=identity#run)

### Rule types: source precedence, recency, confidence, and field-specific logic

Effective **customer profile survivorship** rarely comes from a single rule pattern. Most mature implementations combine several rule types depending on the attribute.

#### Source precedence

Source precedence is the simplest and often most important approach. It defines a ranked order of systems for a particular field.

For example:

*   `account_owner`: CRM wins over support, commerce, and product systems
*   `last_order_date`: commerce wins over CRM and analytics
*   `last_seen_in_product`: product analytics wins over CRM and support
*   `support_tier`: support platform wins over CRM if the support system is where entitlements are actively managed

Source precedence works well when field ownership is clear and operational responsibility is stable.

However, precedence should be field-specific. Saying "CRM is the source of truth" at a global level is usually too broad to be useful. CRM may be authoritative for some customer attributes while weak or stale for others.

#### Recency rules

Recency can be appropriate when the attribute is expected to change often and the latest trusted update is the most relevant.

Examples include:

*   preferred language, if captured through authenticated preference updates
*   latest product activity timestamp
*   most recent support interaction date
*   current subscription renewal date, if fed by the active billing process

Recency becomes risky when freshness is confused with reliability. A newer value is not always a better value. Teams should define the qualifying conditions for a recent update, such as channel trust level, validation state, or event type.

#### Confidence-based rules

Some values can be evaluated by confidence or quality score rather than strict source rank.

For example:

*   a postal address validated through a checkout flow may deserve priority over one entered in a low-friction newsletter form
*   a phone number confirmed via authentication or service interaction may carry more confidence than a number imported from a legacy list
*   inferred company size from enrichment may be lower confidence than directly managed CRM account data

Confidence-based logic is useful when the same field can arrive from multiple channels with meaningfully different levels of validation.

#### Field-specific conditional logic

This is where survivorship becomes more realistic and more maintainable.

Some fields need rules such as:

*   preserve the current value unless the new source is authoritative
*   accept an update only if the incoming value is non-null and passes validation
*   prefer CRM for business contacts, but prefer commerce for guest purchasers until the account is converted
*   allow product analytics to set `trial_started_date`, but never `contract_status`
*   keep both values when the field is multi-valued, such as roles, interests, or product affinities

A strong **[Customer 360 data model](/services/customer-360-data-architecture)** supports this granularity. It separates stable mastered attributes from volatile signals, distinguishes declared facts from inferred scores, and stores lineage so that teams can inspect where each attribute came from.

### How survivorship affects segmentation, analytics, and downstream activation

Survivorship decisions are not just data engineering details. They shape business outputs.

#### Segmentation

Audience logic depends on trustworthy attributes. If lifecycle stage comes from whichever system updated most recently, segments such as `active customers`, `open opportunities`, or `at-risk accounts` can drift away from operational reality.

For example, if support marks a record as `closed` because a ticket was resolved, and that value incorrectly overwrites a CRM sales stage, campaign targeting may exclude valid prospects or include current customers in acquisition programs.

#### Analytics and reporting

Analytical consistency depends on stable definitions. If region, industry, account status, or product tier can change based on ungoverned merge behavior, reporting trends become hard to interpret.

Teams may see apparent changes in customer mix or funnel performance that are really artifacts of profile assembly logic rather than actual business movement.

This is especially problematic when executive dashboards combine mastered attributes with event-derived measures. If the dimensional fields are unstable, the metrics built on top of them become less credible.

#### Personalization and activation

Activation systems often assume the profile they receive is coherent. If consent status, preferred channel, language, or product ownership are assembled poorly, downstream experiences can become inconsistent or noncompliant.

A few examples:

*   marketing sends to an email address that support recently updated for case handling, but the CRM address was still the only one approved for account communication
*   a customer is targeted as a trial user even though commerce data shows an active paid subscription
*   product messaging references a feature tier based on stale CRM data instead of current entitlement data

These failures are usually not caused by missing data. They are caused by unresolved differences in how systems describe the same customer.

#### Operational trust

Perhaps the biggest effect is cultural. When teams do not trust the profile, they create workarounds. Marketing exports its own list. Support keeps a separate override table. Sales relies on CRM only. Analytics rebuilds classifications downstream.

At that point, the unified profile exists technically but not organizationally.

### Stewardship model: who approves rule changes and monitors anomalies

Because survivorship decisions affect multiple teams, they need stewardship rather than isolated technical ownership.

A practical **[unified customer profile governance](/services/customer-data-governance)** model usually includes several roles.

#### Domain owners

These are the business or operational leaders responsible for the meaning of key attributes.

Examples:

*   CRM operations owns sales-managed account and contact fields
*   support operations owns service status and case-derived indicators
*   commerce or billing operations owns order and subscription facts
*   product data teams own behavioral and usage-derived attributes

Domain owners should define what a field means, when it should change, and which source is authoritative under normal conditions.

#### Data platform or CDP architects

These teams translate business ownership into executable profile assembly logic. They help define merge patterns, schema constraints, lineage capture, exception handling, and observability requirements.

Their job is not to decide every business rule alone. Their job is to make the rules implementable, testable, and maintainable.

#### Governance forum or decision group

Enterprises benefit from a lightweight cross-functional forum that approves material rule changes for shared attributes. This is especially important when a change in one domain can alter activation behavior, reporting consistency, or downstream integrations.

The forum does not need to review every field. It should focus on high-impact attributes such as:

*   identifiers and contactability fields
*   consent and communication preferences
*   lifecycle and customer status fields
*   account hierarchy or parent-child relationships
*   product entitlement or subscription indicators
*   geographic and regulatory classifications

#### Data stewardship and anomaly monitoring

Rules need monitoring in production.

A useful **identity graph data stewardship** practice includes checks such as:

*   sudden spikes in attribute overwrite rates by source
*   increases in null replacement for critical fields
*   unusual oscillation between two values for the same attribute
*   profile completion changes after a source schema update
*   segmentation population shifts after a survivorship rule release

When anomalies appear, teams need a clear escalation path. Was the change caused by a business process update, a source system defect, a mapping change, or a flawed survivorship rule? Without stewardship, those questions linger too long and trust erodes.

### Implementation checklist for governed profile assembly

A practical implementation approach can stay vendor-neutral while still being rigorous.

#### 1\. Inventory profile attributes by business purpose

Group fields into categories such as:

*   identity and matching attributes
*   contact and communication attributes
*   account and CRM-managed attributes
*   support and service attributes
*   commerce and billing attributes
*   product usage and behavioral signals
*   derived or inferred attributes

This helps prevent one merge policy from being applied across very different data types.

#### 2\. Assign field-level ownership

For each important attribute, document:

*   business definition
*   system of primary responsibility
*   acceptable contributing sources
*   whether the field is mastered, derived, inferred, or multi-valued
*   downstream processes that depend on it

This is the foundation for **[CRM attribute precedence](/services/crm-data-integration)** and broader source authority decisions.

#### 3\. Choose survivorship logic per field, not per platform

Define whether each field uses:

*   source precedence
*   recency with conditions
*   confidence scoring
*   conditional override logic
*   append-only or multi-value preservation
*   exception flagging for manual review

This is where enterprise teams often gain the most clarity. A profile should not have one survivorship rule. It should have a governed catalog of survivorship behaviors.

#### 4\. Preserve lineage and timestamps

For critical attributes, store enough metadata to answer:

*   which source supplied the current value
*   when it was last updated
*   what rule selected it
*   what prior value was replaced
*   whether the value was validated, inferred, or manually reviewed

Lineage is essential for troubleshooting and governance. It also makes stakeholder conversations much easier when changes need to be justified.

#### 5\. Define conflict states instead of forcing false certainty

Not every conflict should be auto-resolved.

In some cases, it is better to mark an attribute as disputed or route it for review than to pretend the platform knows the correct value. This is especially true for high-risk fields such as consent status, regulatory geography, or contract-related states.

#### 6\. Separate stable profile attributes from volatile signals

A strong model distinguishes between:

*   durable profile facts, such as account owner or billing country
*   rapidly changing observations, such as last page view or latest feature click
*   computed scores, such as engagement or propensity

Blurring these layers creates unnecessary overwrite pressure and makes the unified profile harder to reason about.

#### 7\. Test with real conflict scenarios

Do not validate survivorship only with clean sample data. Test realistic cases such as:

*   CRM email differs from support email
*   billing country differs from web form country
*   product telemetry shows active usage while CRM marks the account as dormant
*   a null update arrives after a previously verified value
*   two sources alternate updates for the same field over several days

These scenarios reveal where rules are too simplistic.

#### 8\. Monitor production behavior and revisit rules regularly

Survivorship is operational. Review rule performance after source onboarding, schema changes, process redesigns, or major activation issues.

A quarterly review cadence for high-impact attributes is often a practical starting point, especially in environments where multiple systems feed the same customer profile.

### Practical examples of conflicting attributes and rule choices

To make the concept more concrete, consider a few typical enterprise decisions.

**Email address**

*   CRM contains the primary business email used by sales
*   Support captures an alternate address from a ticket submitter
*   Commerce captures a purchaser email during checkout

A sensible approach may be to preserve multiple email roles rather than collapse them into one field. If a single primary email is required, the organization might prioritize verified CRM or authenticated commerce email over ad hoc support input, while retaining lineage and alternates.

**Customer status**

*   CRM says `prospect`
*   Commerce says `active subscriber`
*   Product analytics shows regular usage

Here, commerce may be authoritative for paid status, while CRM may remain authoritative for sales stage. The correct answer may not be one surviving field, but two clearly separated attributes with different meanings.

**Country or region**

*   CRM stores sales territory assignment
*   Commerce stores billing country
*   Web forms capture self-reported location
*   Product systems infer access geography from activity

These are not necessarily conflicting facts. They can represent different business concepts. The right response may be schema refinement, not just a survivorship rule.

**Company name**

*   CRM stores the account legal name
*   Support ticket submitters enter variants
*   Product users self-identify with abbreviations

The unified profile might preserve CRM as the mastered account name while storing submitted variants as aliases or search helpers rather than allowing them to overwrite the canonical value.

This is an important pattern: sometimes survivorship problems are actually [data modeling problems](/services/customer-360-data-architecture) in disguise.

### Closing perspective

Well-designed **CDP survivorship rules** do more than tidy up conflicting fields. They define how the enterprise turns many partial system views into a profile that people can actually trust.

That trust depends on a few principles:

*   identity resolution and survivorship are different disciplines
*   field-level ownership matters more than blanket source-of-truth claims
*   recency should be used selectively, not reflexively
*   some conflicts should be modeled, not overwritten
*   governance and monitoring are ongoing responsibilities, not launch tasks

When these principles are applied consistently, the Customer 360 becomes more than a merged record. It becomes a governed asset that supports segmentation, analytics, service workflows, and activation without hiding unresolved contradictions.

Identity

### Pressure-test your customer profile assembly logic

Find gaps in survivorship rules, lineage, and field ownership before conflicting source data distorts segmentation, reporting, and activation.

[Start identity Health Check→](/cdp-health-check?context=identity#run)[Book identity review→](https://calendar.app.google/HMKLsyWwmfU6foXZA)

No login required. Takes 2–3 minutes.

For enterprise teams, that is the real objective: not just unifying data, but assembling customer profiles in a way that remains explainable, adaptable, and operationally credible as systems and business processes evolve.

Tags: CDP, CDP survivorship rules, Customer 360, Data governance, Customer data

## Explore CDP Governance and Profile Quality

These articles extend the same customer data governance theme by showing how CDP programs break down when rules are missing or inconsistent. Together they cover identity confidence, consent enforcement, activation ownership, and the contract-style controls that keep profiles and downstream use cases trustworthy.

[

![Identity Resolution Pitfalls: How False Merges Damage CDP Trust](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20201112-identity-resolution-false-merges-in-cdp-programs--cover?_a=BAVMn6ID0)

### Identity Resolution Pitfalls: How False Merges Damage CDP Trust

Nov 12, 2020

](/blog/20201112-identity-resolution-false-merges-in-cdp-programs)

[

![CDP Suppression Logic Governance: The Hidden Rules That Prevent Audience Activation Mistakes](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20251106-cdp-suppression-logic-governance-for-audience-activation--cover?_a=BAVMn6ID0)

### CDP Suppression Logic Governance: The Hidden Rules That Prevent Audience Activation Mistakes

Nov 6, 2025

](/blog/20251106-cdp-suppression-logic-governance-for-audience-activation)

[

![Consent Drift in CDP Event Pipelines: Why Privacy Rules Break Between Collection and Activation](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20241008-consent-drift-in-cdp-event-pipelines--cover?_a=BAVMn6ID0)

### Consent Drift in CDP Event Pipelines: Why Privacy Rules Break Between Collection and Activation

Oct 8, 2024

](/blog/20241008-consent-drift-in-cdp-event-pipelines)

[

![CDP Implementation Pitfalls: Why Customer Data Programs Stall After the Pilot](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260317-cdp-implementation-pitfalls-why-customer-data-programs-stall-after-the-pilot--cover?_a=BAVMn6ID0)

### CDP Implementation Pitfalls: Why Customer Data Programs Stall After the Pilot

Mar 17, 2026

](/blog/20260317-cdp-implementation-pitfalls-why-customer-data-programs-stall-after-the-pilot)

[

![Why Customer Data Platforms Fail Without Activation Ownership](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20221108-why-customer-data-platforms-fail-without-activation-ownership--cover?_a=BAVMn6ID0)

### Why Customer Data Platforms Fail Without Activation Ownership

Nov 8, 2022

](/blog/20221108-why-customer-data-platforms-fail-without-activation-ownership)

## Explore CDP Governance and Activation Services

This article is most relevant to teams that need to turn profile-quality rules into a governed CDP operating model. These services help define survivorship, identity, consent, and activation patterns so customer data stays trustworthy as it moves between CRM, product, support, and downstream channels. They also provide the architecture and implementation support needed to operationalize those rules across integrations and data flows.

[

### Customer Data Governance

Stewardship, standards, and CDP data policy and controls

Learn More

](/services/customer-data-governance)[

### Identity Resolution Strategy

Cross-channel identity stitching with governed matching rules

Learn More

](/services/identity-resolution-strategy)[

### Customer 360 Data Architecture

Unified customer profile design across identities and events

Learn More

](/services/customer-360-data-architecture)[

### CDP Platform Architecture

CDP event pipeline architecture and identity foundations

Learn More

](/services/cdp-platform-architecture)[

### Customer Data Infrastructure

Operate CDP operations engineering across ingestion, identity, and activation pipelines

Learn More

](/services/customer-data-infrastructure)[

### Customer Data Observability

CDP monitoring and data reliability for customer data

Learn More

](/services/customer-data-observability)

## Explore Governance and Data Integration Case Studies

These case studies show how governed content models, integration-heavy platforms, and structured delivery decisions keep complex digital experiences reliable. They provide practical context for managing conflicting data sources, operational rules, and long-term platform trust across CRM, support, commerce, and product systems.

\[01\]

### [OrganogenesisScalable Multi-Brand Next.js Monorepo Platform](/projects/organogenesis-biotechnology-healthcare "Organogenesis")

[![Project: Organogenesis](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-organogenesis--challenge--01)](/projects/organogenesis-biotechnology-healthcare "Organogenesis")

[Learn More](/projects/organogenesis-biotechnology-healthcare "Learn More: Organogenesis")

Industry: Biotechnology / Healthcare

Business Need:

Organogenesis faced operational challenges managing multiple brand websites on outdated platforms, resulting in fragmented workflows, high maintenance costs, and limited scalability across a multi-brand digital presence.

Challenges & Solution:

*   Migrated legacy static brand sites to a modern AWS-compatible marketing platform. - Consolidated multiple sites into a single NX monorepo to reduce delivery time and maintenance overhead. - Introduced modern Next.js delivery with Tailwind + shadcn/ui design system. - Built a CDP layer using GA4 + GTM + Looker Studio with advanced tracking enhancements.

Outcome:

The transformation reduced time-to-deliver marketing updates by 20–25%, improved Lighthouse scores to ~90+, and delivered a scalable multi-brand foundation for long-term growth.

\[02\]

### [JYSKGlobal Retail DXP & CDP Transformation](/projects/jysk-global-retail-dxp-cdp-transformation "JYSK")

[![Project: JYSK](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-jysk--challenge--01)](/projects/jysk-global-retail-dxp-cdp-transformation "JYSK")

[Learn More](/projects/jysk-global-retail-dxp-cdp-transformation "Learn More: JYSK")

Industry: Retail / E-Commerce

Business Need:

JYSK required a robust retail Digital Experience Platform (DXP) integrated with a Customer Data Platform (CDP) to enable data-driven design decisions, enhance user engagement, and streamline content updates across more than 25 local markets.

Challenges & Solution:

*   Streamlined workflows for faster creative updates. - CDP integration for a retail platform to enable deeper customer insights. - Data-driven design optimizations to boost engagement and conversions. - Consistent UI across Drupal and React micro apps to support fast delivery at scale.

Outcome:

The modernized platform empowered JYSK’s marketing and content teams with real-time insights and modern workflows, leading to stronger engagement, higher conversions, and a scalable global platform.

“Oleksiy (PathToProject) worked with me on a specific project over a period of three months. He took full ownership of the project and successfully led it to completion with minimal initial information. His technical skills are unquestionably top-tier, and working with him was a pleasure. I would gladly collaborate with Oleksiy again at any opportunity. ”

Nikolaj Stockholm NielsenStrategic Hands-On CTO | E-Commerce Growth

\[03\]

### [VeoliaEnterprise Drupal Multisite Modernization (Acquia Site Factory, 200+ Sites)](/projects/veolia-environmental-services-sustainability "Veolia")

[![Project: Veolia](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-veolia--challenge--01)](/projects/veolia-environmental-services-sustainability "Veolia")

[Learn More](/projects/veolia-environmental-services-sustainability "Learn More: Veolia")

Industry: Environmental Services / Sustainability

Business Need:

With Drupal 7 reaching end-of-life, Veolia needed a Drupal 7 to Drupal 10 enterprise migration for its Acquia Site Factory multisite platform—preserving region-specific content and multilingual capabilities across more than 200 sites.

Challenges & Solution:

*   Supported Acquia Site Factory multisite architecture at enterprise scale (200+ sites). - Ported the installation profile from Drupal 7 to Drupal 10 while ensuring platform stability. - Delivered advanced configuration management strategy for safe incremental rollout across released sites. - Improved page loading speed by refactoring data fetching and caching strategies.

Outcome:

The platform was modernized into a stable, scalable multisite foundation with improved performance, maintainability, and long-term upgrade readiness.

“As Dev Team Lead on my project for 10 months, Oleksiy (PathToProject) demonstrated excellent technical skills and the ability to handle complex Drupal projects. His full-stack expertise is highly valuable. ”

Laurent PoinsignonDomain Delivery Manager Web at TotalEnergies

\[04\]

### [Copernicus Marine ServiceCopernicus Marine Service Drupal DXP case study — Marine data portal modernization](/projects/copernicus-marine-service-environmental-science-marine-data "Copernicus Marine Service")

[![Project: Copernicus Marine Service](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-copernicus--challenge--01)](/projects/copernicus-marine-service-environmental-science-marine-data "Copernicus Marine Service")

[Learn More](/projects/copernicus-marine-service-environmental-science-marine-data "Learn More: Copernicus Marine Service")

Industry: Environmental Science / Marine Data

Business Need:

The existing marine data portal relied on three unaligned WordPress installations and embedded PHP code, creating inefficiencies and risks in content management and usability.

Challenges & Solution:

*   Migrated three legacy WordPress sites and a Drupal 7 site to a unified Drupal-based platform. - Replaced risky PHP fragments with configurable Drupal components. - Improved information architecture and user experience for data exploration. - Implemented integrations: Solr search, SSO (SAML), and enhanced analytics tracking.

Outcome:

The new Drupal DXP streamlined content operations and improved accessibility, offering scientists and businesses a more efficient gateway to marine data services.

“Oleksiy (PathToProject) is demanding and responsive. Comfortable with an Agile approach and strong technical skills, I appreciate the way he challenges stories and features to clarify specifications before and during sprints. ”

Olivier RitlewskiIngénieur Logiciel chez EPAM Systems

\[05\]

### [United Nations Convention to Combat Desertification (UNCCD)United Nations website migration to a unified Drupal DXP](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[![Project: United Nations Convention to Combat Desertification (UNCCD)](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-unccd--challenge--01)](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[Learn More](/projects/unccd-united-nations-convention-to-combat-desertification "Learn More: United Nations Convention to Combat Desertification (UNCCD)")

Industry: International Organization / Environmental Policy

Business Need:

UNCCD operated four separate websites (two WordPress, two Drupal), leading to inconsistencies in design, content management, and user experience. A unified, scalable solution was needed to support a large-scale CMS migration project and improve efficiency and usability.

Challenges & Solution:

*   Migrating all sites into a single, structured Drupal-based platform (government website Drupal DXP approach). - Implementing Storybook for a design system and consistency, reducing content development costs by 30–40%. - Managing input from 27 stakeholders while maintaining backend stability. - Integrating behavioral tracking, A/B testing, and optimizing performance for strong Google Lighthouse scores. - Converting Adobe InDesign assets into a fully functional web experience.

Outcome:

The modernization effort resulted in a cohesive, user-friendly, and scalable website, improving content management efficiency and long-term digital sustainability.

“It was my pleasure working with Oleksiy (PathToProject) on a new Drupal website. He is a true full-stack developer—the ideal mix of DevOps expertise, deep front-end knowledge, and the structured thinking of a senior back-end developer. He is well-organized and never lets anything slip. Oleksiy understands what needs to be done before being asked and can manage a project independently with minimal involvement from clients, product managers, or business analysts. One of the best consultants I’ve worked with so far. ”

Andrei MelisTechnical Lead at Eau de Web

\[06\]

### [London School of Hygiene & Tropical Medicine (LSHTM)Higher Education Drupal Research Data Platform](/projects/lshtm-london-school-of-hygiene-tropical-medicine "London School of Hygiene & Tropical Medicine (LSHTM)")

[![Project: London School of Hygiene & Tropical Medicine (LSHTM)](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-lshtm--challenge--01)](/projects/lshtm-london-school-of-hygiene-tropical-medicine "London School of Hygiene & Tropical Medicine (LSHTM)")

[Learn More](/projects/lshtm-london-school-of-hygiene-tropical-medicine "Learn More: London School of Hygiene & Tropical Medicine (LSHTM)")

Industry: Healthcare & Research

Business Need:

LSHTM required improvements to its existing higher education Drupal platform to better manage and distribute complex research data, including support for third-party integrations, Drupal performance optimization, and more reliable synchronization.

Challenges & Solution:

*   Implemented CSV-based data import and export functionality. - Enabled dataset downloads for external consumers. - Improved performance of data-heavy pages and research content delivery. - Stabilized integrations and sync flows across multiple data sources.

Outcome:

The solution improved data accessibility, streamlined research workflows, and enhanced system performance, enabling LSHTM to manage complex datasets more efficiently.

“Oleksiy (PathToProject) has been a valuable developer resource over the past six months for us at LSHTM. This included coming on board to revive and complete a stalled Drupal upgrade project, as well as carrying out work to improve our site accessibility and functionality. I have found Oleksiy to be very knowledgeable and skilful and would happily work with him again in the future. ”

Ali KazemiWeb & Digital Manager at London School of Hygiene & Tropical Medicine

![Oleksiy (Oly) Kalinichenko](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_200,h_200,g_center,f_avif,q_auto:good/v1/contant--oly)

### Oleksiy (Oly) Kalinichenko

#### CTO at PathToProject

[](https://www.linkedin.com/in/oleksiy-kalinichenko/ "LinkedIn: Oleksiy (Oly) Kalinichenko")

### Do you want to start a project?

Send