# When Content Federation Is Better Than a CMS Migration: A Decision Framework for Enterprise Replatforming

Mar 11, 2025

Enterprise teams often start replatforming with an assumption: fragmented content should be consolidated into one CMS. Sometimes that is the right move. Often it is not.

This article offers a practical framework for evaluating **content federation vs CMS migration** in complex estates. It looks at source-of-truth boundaries, governance, search, preview, localization, and operational support so platform leaders can make a lower-risk decision without treating migration or federation as ideology.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20250311-when-content-federation-is-better-than-cms-migration "Summarize this page with ChatGPT")[](https://claude.ai/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20250311-when-content-federation-is-better-than-cms-migration "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%2F20250311-when-content-federation-is-better-than-cms-migration "Summarize this page with Gemini")[](https://x.com/i/grok?text=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20250311-when-content-federation-is-better-than-cms-migration "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%2F20250311-when-content-federation-is-better-than-cms-migration "Summarize this page with Perplexity")

![Blog: When Content Federation Is Better Than a CMS Migration: A Decision Framework for Enterprise Replatforming](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20250311-when-content-federation-is-better-than-cms-migration--cover)

Enterprise replatforming programs often begin with a clean-state ambition: unify content, retire legacy systems, and move everything into a modern platform. That can be a sensible goal when the estate is genuinely duplicative, poorly governed, or impossible to scale. But in large organizations, fragmented content rarely exists by accident alone. It often reflects different business units, regulatory contexts, product lines, regional operating models, or publishing workflows that evolved for real reasons.

That is why **content federation vs CMS migration** should be treated as an architectural decision, not a tooling preference.

A migration consolidates content into a target platform and shifts editorial, delivery, and governance responsibilities into that environment. Federation keeps some content in its existing systems and composes experiences across multiple governed sources at runtime, build time, or through indexing pipelines. Neither approach is universally better. Each changes where complexity lives.

Migration tends to concentrate complexity upfront in modeling, transformation, editorial change management, and cutover planning. Federation tends to preserve local ownership while pushing complexity into integration, caching, search, preview, observability, and support. The right choice depends on whether your organization is better served by centralization or by controlled coexistence.

For enterprise teams, the mistake is usually not choosing the "wrong tool." It is underestimating the operating implications of the chosen approach.

### Why consolidation is not always the right target state

Consolidation is attractive because it promises simplicity. One platform, one authoring model, one workflow layer, one integration surface. In practice, enterprise estates do not become simpler just because content is moved into one repository.

A single platform can still contain:

*   multiple ownership models
*   region-specific compliance requirements
*   incompatible publishing cadences
*   shared and local taxonomies
*   divergent localization workflows
*   separate release windows across channels and brands

In those cases, a migration may centralize storage without actually reducing coordination cost.

There is also a common strategic overreach in replatforming: treating all content as if it should become one uniform asset base. That assumption breaks down when the content has different legal ownership, different quality expectations, or different lifecycles. Product content managed by a commerce team, regulated content maintained by a legal or medical review process, and campaign content created by a brand team may all be published into the same customer journey, but they do not necessarily belong in the same authoring system.

A federated model can be a better fit when it respects those source-of-truth boundaries rather than forcing an artificial one-size-fits-all structure.

This is not an anti-migration argument, and it is not anti-headless. In many programs, a [headless or composable content platform](/services/content-platform-architecture) becomes the orchestration layer even when not every asset is migrated into it. The important question is not whether one platform _can_ hold everything. It is whether it _should_.

### Signals that content should be migrated, not federated

Federation becomes expensive when the underlying sources are weak, inconsistent, or hard to govern. If the estate is fragmented because of historical sprawl rather than intentional boundaries, migration is often the healthier long-term move.

Strong signals in favor of migration include:

*   **The current systems do not have stable APIs or reliable content access patterns.** If source systems require custom extraction logic, inconsistent authentication, brittle schemas, or manual workarounds, federation can create a fragile delivery layer.
*   **Content is duplicated across systems with no clear owner.** If multiple teams are editing near-identical content in parallel, federation preserves ambiguity rather than resolving it.
*   **Editorial workflows need to be standardized.** When the organization wants common review, approval, scheduling, and release practices, migration usually supports that objective better than stitching together several workflow engines.
*   **The delivery experience depends on shared structured models.** If pages, modules, metadata, and channel outputs need to be assembled consistently across brands or markets, migration can reduce transformation overhead.
*   **Legacy platforms are a material operational risk.** If support contracts, security posture, upgradeability, or staffing constraints make existing systems difficult to sustain, federation may only delay unavoidable retirement work.
*   **Search quality is suffering because source metadata is inconsistent.** Federation can aggregate content, but it does not magically normalize poor semantics. If discoverability depends on stronger content structure, migration may be necessary.

Migration is also often the better choice when an organization is truly pursuing platform standardization rather than just website delivery modernization. If success depends on unifying operating model, governance, and editorial process, then the content layer usually has to move along with the frontend and experience architecture.

### Signals that federation is the safer and cheaper option

Federation is most valuable when content fragmentation reflects legitimate business boundaries and when those systems are already governable enough to participate in a broader experience platform.

Signals in favor of federation include:

*   **There are clear source-of-truth domains.** For example, a product system owns specifications, a DAM owns media, a regulatory repository owns approved statements, and a CMS owns campaign narrative.
*   **The source systems are stable and API-capable.** Federation works far better when systems expose consistent identifiers, metadata, and retrieval patterns.
*   **The cost of editorial migration outweighs the user benefit.** Large enterprises often hold years of content that does not justify remodel-and-move effort if it is already maintained correctly where it lives.
*   **Different teams need to retain operational autonomy.** In multi-brand or multi-region organizations, forcing every team into a single publishing workflow can slow delivery more than it helps.
*   **The replatforming timeline is driven by frontend modernization, not repository rationalization.** If the pressing need is to improve performance, design system adoption, channel orchestration, or release velocity, federation can decouple delivery progress from a long migration program.
*   **Legal, regional, or contractual constraints limit centralization.** Some content domains cannot be moved easily because of ownership, process controls, or compliance obligations.

In these situations, federation can reduce program risk by avoiding a large content cutover while still enabling a modern digital experience layer.

But that only works if federation is governed deliberately. Without defined contracts, ownership, and support models, it becomes a polite word for distributed chaos.

### Governance, search, preview, and caching implications

Enterprise teams often compare federation and migration at the architecture diagram level and miss the day-two operating realities. That is where many replatform programs either stabilize or become expensive.

#### Governance

Migration usually improves governance when the organization can actually adopt the new model. One platform can make it easier to define lifecycle states, permissions, schema standards, editorial accountability, and auditability.

Federation, by contrast, requires **governance across systems**. That means agreeing on:

*   which system owns which content domain
*   what identifiers are canonical
*   how metadata is normalized
*   how changes are versioned and propagated
*   who resolves conflicts when the same concept appears in multiple systems

If those agreements are weak, federation produces inconsistent experiences and recurring support disputes.

#### Search

Search is one of the most underestimated implications of federation.

When content is migrated, indexing tends to be more straightforward because structured fields, taxonomy, and publication status can be derived from one managed source. In a federated model, search quality depends on your ability to create a usable [indexing pipeline](/services/headless-cms-architecture) across heterogeneous content.

Key questions include:

*   Is search indexing done directly from source systems, from the experience layer, or from an intermediate aggregation service?
*   How will inconsistent metadata be mapped into a shared search schema?
*   What determines freshness and reindex triggers?
*   How will duplicate or near-duplicate records be handled across sources?
*   Can access controls or market-specific visibility rules be enforced consistently?

A federated experience can still support excellent search, but only if search is treated as a first-class architectural concern rather than an afterthought.

#### Preview

Preview is another area where federation can look simple on a roadmap and become difficult in delivery.

In a single migrated platform, preview often follows one workflow: unpublished content is assembled in a controlled environment and rendered using a known draft state.

In a federated architecture, preview may require draft awareness across multiple systems, each with different APIs, authentication mechanisms, and publication states. Some source systems may not support draft retrieval at all. Others may expose preview differently for structured fields versus assets. That affects what editors can verify before publishing.

If end-to-end preview is important, the team should define early whether preview will be:

*   full-journey and multi-source
*   partial by content domain
*   simulated through snapshots or staging indexes
*   limited to the orchestration layer only

This decision has major implications for editorial trust.

#### Caching and performance

Federation can preserve business autonomy, but it shifts pressure onto integration and caching strategy.

You need to decide whether content is composed:

*   at request time
*   at build time
*   through scheduled synchronization
*   through event-driven materialization into a read-optimized store

Each option changes freshness, resilience, and failure behavior.

For example, request-time federation can keep content current but increases dependency on upstream system latency and availability. Materialized aggregation can improve speed and resilience but introduces synchronization lag and operational complexity. Neither is inherently correct; the decision depends on user expectations, source change frequency, and tolerance for stale content.

### Dependency mapping across content, identity, search, and frontend layers

A replatforming decision becomes clearer when content is mapped as part of a wider delivery system rather than as a standalone CMS problem.

In enterprise estates, content dependencies often run across four connected layers.

#### 1\. Content layer

This includes CMS platforms, DAMs, PIMs, knowledge bases, regulatory repositories, and local publishing systems. The main concern here is ownership, structure, and lifecycle.

#### 2\. Identity and access layer

Some content is public. Some is personalized, gated, regionalized, or role-restricted. If content visibility depends on identity or entitlement, federation decisions must account for where access rules are evaluated and enforced.

#### 3\. Search and discovery layer

Search, recommendations, and internal linking often rely on normalized metadata and stable identifiers. A fragmented content estate can still support coherent discovery, but only if indexing contracts are explicit.

#### 4\. Frontend and experience layer

The frontend is where content differences become user-visible. This layer has to handle layout composition, rendering fallbacks, localization logic, preview mode, analytics instrumentation, and resilience when one source is unavailable.

When these dependencies are not mapped, enterprise teams often underestimate the blast radius of either migration or federation.

A useful exercise is to create a dependency matrix for each major content domain:

*   source system
*   business owner
*   consuming channels
*   search requirements
*   localization dependencies
*   preview needs
*   identity constraints
*   expected freshness
*   failure tolerance
*   retirement likelihood over the next 2-3 years

This makes the decision less theoretical. It exposes which domains are good candidates for migration, which are good candidates for federation, and which should be deferred until upstream systems are improved.

### A step-by-step decision framework for enterprise teams

The most effective enterprise programs do not treat migration and federation as mutually exclusive. They evaluate content domains individually and choose the model that best fits each one.

Here is a practical decision framework.

#### Step 1: Define the business outcome of the replatform

Be explicit about what the program is trying to improve.

If the primary goal is:

*   standardized editorial operations
*   platform rationalization
*   governance unification
*   schema consistency across channels

then migration may be the primary strategy.

If the primary goal is:

*   faster frontend modernization
*   experience unification across existing systems
*   lower transition risk
*   preservation of local ownership

then federation may be the stronger starting point.

#### Step 2: Identify content domains, not just systems

Do not evaluate only at the system level. One platform may contain several content domains with different characteristics, and one domain may be spread across several systems.

Examples might include:

*   product data
*   brand narrative content
*   support documentation
*   legal or regulated statements
*   media assets
*   location or partner information

Decisions made at the domain level are usually more accurate than blanket platform decisions.

#### Step 3: Score each domain across core decision criteria

Use a simple qualitative scale such as low, medium, or high for factors like:

*   source-of-truth clarity
*   API maturity
*   schema consistency
*   editorial change cost
*   search normalization effort
*   preview feasibility
*   localization complexity
*   operational support burden
*   dependency on identity or entitlements
*   business criticality during transition

Domains with weak APIs, poor ownership clarity, and high inconsistency often need migration or remediation. Domains with strong ownership and stable interfaces are often good federation candidates.

#### Step 4: Decide where complexity is easier to carry

This is the core tradeoff.

Ask whether your organization is better prepared to carry complexity in:

*   migration planning and editorial transformation
*   or long-term integration and cross-system operations

Some enterprises are strong at centralized platform governance and can absorb migration well. Others operate through federated business units and will struggle more with forced consolidation than with controlled interoperability.

#### Step 5: Define non-negotiable experience capabilities

Before choosing an approach, clarify expectations for:

*   search relevance and freshness
*   preview fidelity
*   localization workflow
*   publishing speed
*   resilience and fallback behavior
*   analytics consistency

If the chosen architecture cannot support these capabilities credibly, it is the wrong choice even if it looks efficient on a roadmap.

#### Step 6: Separate transition architecture from target architecture

A common mistake is assuming the transition state must equal the long-term state.

Federation can be an effective transition pattern while selected domains are gradually migrated over time. Likewise, a target architecture may remain intentionally federated in some areas because that is the right operating model.

The key is to distinguish:

*   what must change now to deliver business value
*   what can remain in place safely
*   what should be retired later under a separate roadmap

#### Step 7: Put operating model decisions in writing

Whichever path you choose, document the model clearly.

For migration, define governance, ownership transfer, content model stewardship, workflow standards, and decommission criteria.

For federation, define source contracts, metadata standards, indexing strategy, cache policy, preview expectations, support responsibilities, and incident ownership.

Architectures fail in practice when these decisions remain implicit.

### A balanced way to think about the choice

The most mature enterprise replatforming strategies are rarely purely centralized or purely federated. They are selective.

They migrate content that needs stronger governance, shared structure, or platform standardization. They federate content that already has a stable source of truth, legitimate ownership boundaries, or a poor cost-benefit case for relocation. And they avoid simplistic promises that one repository will automatically become a perfect single source of truth.

That is the real decision framework: not "Which approach is more modern?" but "Which approach places complexity where our organization can govern it best?"

If the answer is migration, do it for the right reasons and with full awareness of editorial and operational change. If the answer is federation, do it as a disciplined architectural pattern, not as an excuse to leave fragmentation unmanaged. Programs such as [Copernicus Marine Service](/projects/copernicus-marine-service-environmental-science-marine-data) show where consolidation and migration are justified, while large-scale estates like [Veolia](/projects/veolia-environmental-services-sustainability) illustrate how governance, integration stability, and caching strategy become central to the operating model.

In enterprise content platforms, that distinction is what turns replatforming from a technology project into a durable operating model.

Tags: Headless, Enterprise CMS, Content Federation, CMS Migration, Replatforming, Architecture

## Explore Content Federation and Replatforming Tradeoffs

These articles extend the decision framework by showing what changes when enterprise content is replatformed, federated, or left distributed. They cover the operational risks that often determine success, including search, localization, preview, observability, and dependency management. Together they help teams evaluate not just the target architecture, but the support model it requires.

[

![Why Enterprise Search Breaks After a CMS Replatform and How to Prevent It](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20210527-why-enterprise-search-breaks-after-a-cms-replatform--cover?_a=BAVMn6ID0)

### Why Enterprise Search Breaks After a CMS Replatform and How to Prevent It

May 27, 2021

](/blog/20210527-why-enterprise-search-breaks-after-a-cms-replatform)

[

![Localization Fallback Rules in Multi-Region Content Platforms: The Modeling Decisions That Prevent Publishing Chaos](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20221116-localization-fallback-rules-in-multi-region-content-platforms--cover?_a=BAVMn6ID0)

### Localization Fallback Rules in Multi-Region Content Platforms: The Modeling Decisions That Prevent Publishing Chaos

Nov 16, 2022

](/blog/20221116-localization-fallback-rules-in-multi-region-content-platforms)

[

![Headless Preview Architecture: Why Editorial Confidence Drops Without It](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20230919-headless-preview-architecture-for-editorial-teams--cover?_a=BAVMn6ID0)

### Headless Preview Architecture: Why Editorial Confidence Drops Without It

Sep 19, 2023

](/blog/20230919-headless-preview-architecture-for-editorial-teams)

[

![Redirect Governance Before an Enterprise CMS Migration: Why URL Decisions Become Cutover Risk](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20240814-redirect-governance-before-enterprise-cms-migration--cover?_a=BAVMn6ID0)

### Redirect Governance Before an Enterprise CMS Migration: Why URL Decisions Become Cutover Risk

Aug 14, 2024

](/blog/20240814-redirect-governance-before-enterprise-cms-migration)

[

![Headless Platform Observability: What to Instrument Before Production Incidents Expose the Gaps](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260407-headless-platform-observability-architecture-before-production-incidents--cover?_a=BAVMn6ID0)

### Headless Platform Observability: What to Instrument Before Production Incidents Expose the Gaps

Apr 7, 2026

](/blog/20260407-headless-platform-observability-architecture-before-production-incidents)

[

![Headless API Dependency Budgets: How to Prevent Latency Cascades in Composable Platforms](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260417-headless-api-dependency-budgets-for-composable-platforms--cover?_a=BAVMn6ID0)

### Headless API Dependency Budgets: How to Prevent Latency Cascades in Composable Platforms

Apr 17, 2026

](/blog/20260417-headless-api-dependency-budgets-for-composable-platforms)

## Explore Content Architecture and Federation Services

If you are weighing federation against a full CMS migration, these services help turn that decision into an executable platform plan. They cover the content modeling, governance, integration, and migration work needed to support either controlled coexistence or a structured replatforming path. They are a strong next step for teams that need help designing the target architecture and operating model before committing to implementation.

[

### Customer Data Governance

Stewardship, standards, and CDP data policy and controls

Learn More

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

### CDP Platform Architecture

CDP event pipeline architecture and identity foundations

Learn More

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

### Customer 360 Data Architecture

Unified customer profile design across identities and events

Learn More

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

### Customer Data Modeling

Customer profile and event schema engineering

Learn More

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

### 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 Federation and Multisite Delivery

These case studies show how enterprise teams handled fragmented content, governed multiple sources, and chose between consolidation and controlled coexistence. They add practical context for deciding when to migrate, when to federate, and how to keep search, localization, and operations reliable at scale.

\[01\]

### [AlproHeadless CMS Case Study: Global Consumer Brand Platform (Contentful + Gatsby)](/projects/alpro-headless-cms-platform-for-global-consumer-content "Alpro")

[![Project: Alpro](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-alpro--challenge--01)](/projects/alpro-headless-cms-platform-for-global-consumer-content "Alpro")

[Learn More](/projects/alpro-headless-cms-platform-for-global-consumer-content "Learn More: Alpro")

Industry: Food & Beverage / Consumer Goods

Business Need:

Users were abandoning the website before fully engaging with content due to slow loading times and an overall poor performance experience.

Challenges & Solution:

*   Implemented a fully headless architecture using Gatsby and Contentful. - Eliminated loading delays, enabling fast navigation and filtering. - Optimized performance to ensure a smooth user experience. - Delivered scalable content operations for global marketing teams.

Outcome:

The updated platform significantly improved speed and usability, resulting in higher user engagement, longer session durations, and increased content exploration.

\[02\]

### [ArvestaHeadless Corporate Marketing Platform (Gatsby + Contentful) with Storybook Components](/projects/arvesta "Arvesta")

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

[Learn More](/projects/arvesta "Learn More: Arvesta")

Industry: Agriculture / Food / Corporate & Marketing

Business Need:

Arvesta required a modern, scalable headless CMS for enterprise corporate marketing—supporting rapid updates, structured content operations, and consistent UI delivery across multiple teams and repositories.

Challenges & Solution:

*   Implemented a component-driven delivery workflow using Storybook variants as the single source of UI truth. - Defined scalable content models and editorial patterns in Contentful for marketing and corporate teams. - Delivered rapid front-end engineering support to reduce load on the in-house team and accelerate releases. - Integrated ElasticSearch Cloud for fast, dynamic content discovery and filtering. - Improved reuse and consistency through a shared UI library aligned with the System UI theme specification.

Outcome:

The platform enabled faster delivery of marketing updates, improved UI consistency across pages, and strengthened editorial operations through structured content models and reusable components.

\[03\]

### [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

\[04\]

### [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

\[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\]

### [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

![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