# AEM Live Copy and Rollout Governance Before Drupal Migration

Jun 4, 2026

By Oleksiy Kalinichenko

AEM to Drupal programs often underestimate how much publishing behavior is hidden inside Live Copy inheritance, rollout configurations, and market-specific exceptions.

This article explains why **AEM Live Copy migration planning** should start with an operating model audit, not just a content export. It covers inheritance rules, local overrides, approval paths, and the migration decisions needed to preserve useful behavior without recreating accidental complexity in Drupal.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260604-aem-live-copy-rollout-governance-before-drupal-migration "Summarize this page with ChatGPT")[](https://claude.ai/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260604-aem-live-copy-rollout-governance-before-drupal-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%2F20260604-aem-live-copy-rollout-governance-before-drupal-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%2F20260604-aem-live-copy-rollout-governance-before-drupal-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%2F20260604-aem-live-copy-rollout-governance-before-drupal-migration "Summarize this page with Perplexity")

![Blog: AEM Live Copy and Rollout Governance Before Drupal Migration](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20260604-aem-live-copy-rollout-governance-before-drupal-migration--cover)

A migration from AEM to Drupal is rarely just a platform move. In enterprise environments, it is also a change to how regional teams inherit content, how local markets diverge from global standards, and how governance is enforced through process rather than policy documents.

That is why **AEM Live Copy migration planning** deserves more attention than it often gets.

Many organizations know they are using AEM Multi Site Manager concepts, but they do not always have a complete view of how inheritance, rollout triggers, detached branches, or local edits actually shape publishing behavior. Over time, those patterns become part of the operating model. They influence who owns content, when updates are pushed, which markets are allowed to vary, and where approval paths intervene.

If that behavior is not documented before a Drupal migration begins, teams can make the wrong assumptions in both directions. They may try to rebuild every inherited relationship even when it no longer serves the business, or they may flatten complex market dependencies into a simpler Drupal model without understanding the consequences.

The goal is not to chase exact feature parity. In most cases, that would be the wrong objective anyway. The goal is to understand which behaviors are essential, which are compensating for old governance problems, and which can be simplified as part of the move.

### Why Live Copy behavior becomes migration risk

Live Copy structures often look like content relationships, but they are also governance relationships.

A parent-child market structure can encode decisions such as:

*   which teams can inherit global changes automatically
*   which regions require manual review before accepting updates
*   which page components are expected to remain shared
*   which content areas are routinely localized
*   which parts of the site have been detached from the standard operating model

When migration teams treat this only as a page tree problem, they miss the real risk: publishing behavior is being transferred from one platform to another without a shared understanding of how it works.

That creates several common issues.

First, content ownership becomes unclear. A global team may assume it controls updates downstream, while regional teams may depend on local override patterns that are invisible in a high-level site map.

Second, workflow assumptions break. A rollout may have functioned as a de facto approval signal in AEM, even if no one described it that way. After migration, Drupal workflows may be configured around content states and editorial roles, but not around inherited update expectations.

Third, localization cost increases unexpectedly. Teams often discover late in the program that markets are not simply translating content. They are selectively inheriting, partially overriding, or rejecting specific upstream changes.

Fourth, cutover validation becomes harder. If no one can state what should happen when a global page changes, it becomes difficult to verify whether the Drupal implementation is correct.

In short, undocumented rollout behavior turns into migration risk because it affects architecture, governance, workflow, QA, and adoption at the same time.

### What to inventory: inheritance, rollout triggers, local overrides, detached branches

A useful **rollout configuration audit** should not begin with a platform comparison spreadsheet. It should begin with a structured discovery exercise that captures how the organization publishes across markets today.

A practical inventory usually includes four layers.

#### 1\. Inheritance structure

Start by mapping the major content relationships.

Document:

*   global source sites or master branches
*   regional or country-level descendants
*   business-unit variations
*   exceptions where some markets inherit from different parents
*   content types or page templates that follow different patterns

This is the baseline for **content inheritance mapping**. The purpose is not just to identify hierarchy, but to identify where governance intent is embedded in that hierarchy.

Ask questions such as:

*   Which sites are expected to inherit shared structure?
*   Which sections are centrally managed?
*   Which sections are locally owned?
*   Are there different inheritance rules for campaign pages, product pages, support content, or legal content?

Often, the answers vary by content domain more than teams expect.

#### 2\. Rollout triggers and update mechanics

Next, document how upstream changes move downstream.

Do not assume all rollouts behave the same way. In practice, organizations often have a mix of formal configuration, manual habits, and editor workarounds.

Capture:

*   what kinds of source updates typically flow to child markets
*   whether updates are expected immediately, periodically, or after review
*   who initiates the process in practice
*   which content elements are commonly included or excluded
*   whether structural changes are treated differently from text changes
*   where teams rely on manual communication instead of system behavior

Even if the implementation details are complex, the migration team needs the operational truth: what business users believe will happen when headquarters updates content.

#### 3\. Local overrides and inherited breaks

This is often the most important discovery area.

Many markets inherit a large amount of global content while maintaining local exceptions for pricing, messaging, promotions, legal disclosures, contact details, or product availability. Some exceptions are intentional governance choices. Others are one-off deviations that became permanent.

Inventory:

*   fields or components commonly overridden by local teams
*   patterns of frequent inheritance cancellation or breakage
*   content areas with repeated local edits after rollouts
*   components that are technically shared but operationally local
*   override behavior tied to language, region, compliance, or product portfolio

This analysis helps distinguish between legitimate localization and structural friction. If local teams constantly override a supposedly shared component, that component may not belong in a shared model.

#### 4\. Detached branches and unmanaged exceptions

Detached or loosely governed sections deserve specific attention because they often create false confidence in migration plans.

A program may believe it has a clear global-to-local model, but detached branches can tell a different story. These branches often appear in situations such as:

*   acquisitions or merged business units
*   markets with unique legal requirements
*   emergency campaign structures created outside normal governance
*   historical site sections no longer aligned to current standards

If these branches are ignored in discovery, they tend to surface late during content mapping, UAT, or cutover rehearsals.

A good audit flags them early and forces a decision: integrate them into the target model, preserve them as exceptions, or retire them.

### Which behaviors should be preserved, simplified, or retired

A migration is a rare opportunity to separate useful governance from accumulated complexity.

That decision should not be framed as "can Drupal do what AEM did?" It should be framed as "which business behaviors should the future platform support, and at what level of operational cost?"

A simple three-part model helps.

#### Preserve

Preserve behaviors that clearly support business control, brand consistency, or compliance with manageable editorial effort.

Examples can include:

*   centrally managed legal or policy content used across regions
*   shared structural patterns that keep multisite experiences coherent
*   controlled downstream updates for high-risk content domains
*   approval checkpoints for sensitive regional publishing workflows

These are the places where the migration team should design Drupal content models and workflows intentionally around the need.

#### Simplify

Simplify behaviors that have real value but are currently implemented through overly complex inheritance or ad hoc publishing rules.

Examples can include:

*   replacing implicit rollout assumptions with explicit workflow states
*   reducing deep inheritance chains that are hard to reason about
*   narrowing the set of content elements that can inherit automatically
*   moving frequently localized content into a model that expects local ownership

This is often the highest-value category. It preserves business intent while reducing hidden dependencies.

#### Retire

Retire behaviors that exist mainly because the current platform model allowed them to accumulate.

Examples can include:

*   legacy branches with no active ownership model
*   inherited structures that editors routinely bypass
*   exceptions no one can justify or explain
*   duplicated publishing steps that are no longer needed

Retiring complexity is not only a technical decision. It requires stakeholder alignment, because some exceptions may be politically sensitive even when they add little operational value.

A strong migration team makes these decisions visible rather than carrying every legacy pattern forward by default.

### Mapping AEM market relationships into Drupal content and workflow models

When translating **MSM governance** and market relationships into Drupal, the safest approach is to map business capabilities first and implementation patterns second.

Drupal may support the target operating model through a combination of [content architecture](/services/drupal-experience-platform-strategy), editorial permissions, workflow states, translation or localization processes, and deployment practices. But the exact design should be driven by required behavior, not by a one-to-one attempt to recreate AEM concepts.

A useful mapping exercise typically covers five areas.

#### 1\. Content ownership model

Define who owns each major content domain in the target state.

For each domain, identify:

*   global owner
*   regional owner
*   local approver, if needed
*   whether content is centrally created, locally adapted, or locally authored from scratch

This reduces ambiguity and informs both Drupal permissions and editorial workflow design.

#### 2\. Shared versus local content boundaries

Determine what should truly remain shared.

Not all previously inherited content should stay centrally controlled. Some content may perform better as reusable source material, editorial guidance, or design system content rather than as directly inherited page content.

The key is to define boundaries such as:

*   globally standardized components
*   reusable reference content
*   region-specific variants
*   market-owned pages with optional central guidance

This avoids rebuilding inheritance where a cleaner content ownership split would work better.

#### 3\. Workflow and approval paths

AEM rollout behavior sometimes masks process decisions that need to become explicit in Drupal.

For example, a market may previously have received global updates through a rollout pattern but still relied on local editorial review before publication. In Drupal, that may need to be represented as workflow states, approvals, notifications, or release procedures rather than hidden inheritance logic.

Document:

*   when local review is mandatory
*   when global changes can be accepted without review
*   which content categories require compliance approval
*   whether publication is centralized or market-driven

This is especially important for **regional publishing workflows** where organizational responsibility differs by country or business unit, and where [governance architecture](/services/drupal-governance-architecture) needs to make those controls explicit.

#### 4\. Variant strategy

Some market differences are durable and should be modeled as variants. Others are temporary and may be better handled through campaign operations, scheduling, or editorial process.

A migration team should ask:

*   Is this variation persistent across time?
*   Does it affect structure, content, or only presentation?
*   Is it tied to market, language, legal context, or product availability?
*   Does it need independent lifecycle management?

Clear answers help prevent a target-state model from becoming either too rigid or too fragmented.

#### 5\. Governance documentation

The target architecture should include a governance artifact that business and delivery teams can understand.

At minimum, define:

*   source-of-truth content domains
*   local editable areas
*   approval responsibilities
*   exception handling rules
*   retirement criteria for unsupported legacy patterns

This turns migration knowledge into an operating model rather than leaving it inside implementation teams.

### Cutover and validation risks when rollout logic is undocumented

Undocumented rollout behavior does not just affect design. It increases delivery risk during testing and cutover.

The biggest problem is that teams cannot validate what they have not defined.

If a market page changes in Drupal after a global update, is that correct behavior or a defect? If a locally edited section no longer tracks central changes, is that intentional or a missed dependency? If a regional team now has to approve content manually, is that acceptable simplification or a broken process?

Without a documented baseline, these questions turn UAT into opinion-based debate.

Common cutover risks include:

*   missing local overrides that were embedded in inherited page structures
*   over-normalized content models that erase legitimate market differences
*   workflows that slow publishing because hidden approval habits were not recognized
*   incomplete migration of source-to-market relationships for priority content domains
*   post-launch disputes over content ownership and change authority

To reduce these risks, validation should be scenario-based rather than only page-based.

Useful scenarios often include:

*   a global content update to a shared policy page
*   a regional change to product messaging that should remain local
*   a legal or compliance change that requires market review
*   a new market page created from a shared template or reference structure
*   a previously detached branch being migrated, archived, or rebuilt

Scenario testing forces the program to validate operating behavior, not just content presence.

It is also wise to involve editorial and market stakeholders directly in these tests. They are often the only people who understand the practical meaning of historical exceptions.

### A readiness checklist for migration teams

Before implementation goes too far, migration teams should be able to answer a focused set of questions.

#### Governance and discovery

*   Have we mapped the major global, regional, and local content relationships?
*   Do we know which site sections rely on inherited behavior today?
*   Have we identified detached branches and unmanaged exceptions?
*   Can business owners explain why key inheritance patterns exist?

#### Content and operating model

*   Which content domains must remain centrally controlled?
*   Which content areas should become locally owned in the target state?
*   Where are local overrides frequent enough to justify a different model?
*   Have we separated translation needs from true market variation?

#### Workflow and publishing

*   Do we understand current approval paths, whether formal or informal?
*   Which publishing actions require local review in the future state?
*   Are regional publishing workflows documented clearly enough to configure and test?
*   Have we defined who has authority to accept, reject, or modify global updates?

#### Migration design

*   Are we avoiding assumptions about exact feature parity?
*   Have we decided which behaviors to preserve, simplify, or retire?
*   Is the Drupal target model based on business capability rather than legacy implementation detail?
*   Are exceptions handled intentionally instead of deferred indefinitely?

#### Testing and cutover

*   Do we have scenario-based validation for shared and local publishing behavior?
*   Have market stakeholders reviewed proposed handling of critical exceptions?
*   Can we trace migrated content back to agreed ownership and governance rules?
*   Is there a documented fallback plan for unresolved rollout-related edge cases?

If the answer to several of these questions is no, the program is not yet ready to treat migration as a straightforward build-and-move exercise.

### Final thought

AEM Live Copy and rollout behavior often represent years of accumulated publishing decisions. Some of those decisions are valuable and should shape the Drupal target state. Others are artifacts of history, unclear ownership, or workarounds that no longer deserve to survive.

The migration team’s job is not to reproduce the past in a different CMS. It is to understand the current operating model well enough to make deliberate choices.

That is why **AEM Live Copy migration planning** should begin with governance, inheritance, and workflow discovery. When teams audit those relationships early, they can design a Drupal platform that supports real business needs, reduces accidental complexity, and gives global and regional stakeholders a model they can actually explain, govern, and maintain. Programs doing this well usually combine that discovery with structured [AEM to Drupal migration](/services/aem-to-drupal-migration) planning and scenario-based validation, similar to the multisite governance and rollout discipline seen in [Veolia](/projects/veolia-environmental-services-sustainability).

Tags: AEM Live Copy migration planning, AEM to Drupal migration, Drupal, MSM governance, enterprise CMS migration, content inheritance mapping

## Explore AEM to Drupal Migration Governance

These articles extend the same migration lens by showing how hidden dependencies, media governance, freeze exceptions, and multisite standardization affect enterprise cutovers. Together they help you decide what to preserve, simplify, or redesign when moving operating behavior from AEM into Drupal.

[

![AEM to Drupal Migration: The Dependency Mapping Work Most Teams Underestimate](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20230914-aem-to-drupal-migration-dependency-mapping-before-cutover--cover?_a=BAVMn6ID0)

### AEM to Drupal Migration: The Dependency Mapping Work Most Teams Underestimate

Sep 14, 2023

](/blog/20230914-aem-to-drupal-migration-dependency-mapping-before-cutover)

[

![AEM Asset Rendition and Metadata Audits Before Drupal Migration: The DAM Workstream That Prevents Media Chaos Later](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20231010-aem-asset-rendition-and-metadata-audit-before-drupal-migration--cover?_a=BAVMn6ID0)

### AEM Asset Rendition and Metadata Audits Before Drupal Migration: The DAM Workstream That Prevents Media Chaos Later

Oct 10, 2023

](/blog/20231010-aem-asset-rendition-and-metadata-audit-before-drupal-migration)

[

![Drupal Migration Content Freeze Exceptions: How to Keep Publishing Moving Without Losing Cutover Control](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20240314-drupal-content-freeze-exceptions-during-enterprise-migration--cover?_a=BAVMn6ID0)

### Drupal Migration Content Freeze Exceptions: How to Keep Publishing Moving Without Losing Cutover Control

Mar 14, 2024

](/blog/20240314-drupal-content-freeze-exceptions-during-enterprise-migration)

[

![How to Standardize a Drupal Multisite Platform Without Freezing Local Delivery](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20250722-drupal-multisite-standardization-without-blocking-local-teams--cover?_a=BAVMn6ID0)

### How to Standardize a Drupal Multisite Platform Without Freezing Local Delivery

Jul 22, 2025

](/blog/20250722-drupal-multisite-standardization-without-blocking-local-teams)

## Explore Drupal Migration and Governance Services

This article is about preserving complex publishing behavior while moving from AEM to Drupal, so the most relevant next step is help with migration planning, content modeling, and governance design. These services support the target-state architecture, data mapping, and operating model decisions needed to migrate safely without recreating unnecessary complexity.

[

### AEM to Drupal Migration Services

Content and integration migration with controlled cutover

Learn More

](/services/aem-to-drupal-migration)[

### Drupal Migration

Drupal content migration engineering for data, content, and platform change

Learn More

](/services/drupal-migration)[

### Drupal Governance Architecture

Drupal editorial workflow engineering and permissions model design

Learn More

](/services/drupal-governance-architecture)[

### Drupal Content Architecture

Drupal content architecture design and editorial operating design

Learn More

](/services/drupal-content-architecture)[

### Drupal Platform Audit

Enterprise Drupal Technical Assessment & Drupal Health Check

Learn More

](/services/drupal-platform-audit)[

### Drupal Platform Modernization

Enterprise Drupal upgrade strategy for upgradeable delivery

Learn More

](/services/drupal-platform-modernization)

## Explore Governance and Multisite Migration

These case studies show how complex content governance, rollout control, and multi-market delivery were handled in real implementations. They help contextualize what to audit before moving from AEM to Drupal, especially when inheritance, regional exceptions, and release behavior shape the operating model. Together, they illustrate how teams preserved essential behavior while simplifying platform complexity.

\[01\]

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

\[02\]

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

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

### [Bayer Radiología LATAMSecure Healthcare Drupal Collaboration Platform](/projects/bayer-radiologia-latam "Bayer Radiología LATAM")

[![Project: Bayer Radiología LATAM](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-bayer--challenge--01)](/projects/bayer-radiologia-latam "Bayer Radiología LATAM")

[Learn More](/projects/bayer-radiologia-latam "Learn More: Bayer Radiología LATAM")

Industry: Healthcare / Medical Imaging

Business Need:

An advanced healthcare digital platform for LATAM was required to facilitate collaboration among radiology HCPs, distribute company knowledge, refine treatment methods, and streamline workflows. The solution needed secure medical website role-based access restrictions based on user role (HCP / non-HCP) and geographic region.

Challenges & Solution:

*   Multi-level filtering for precise content discovery. - Role-based access control to support different professional needs. - Personalized HCP offices for tailored user experiences. - A structured approach to managing diverse stakeholder expectations.

Outcome:

The platform enhanced collaboration, streamlined workflows, and empowered radiology professionals with advanced tools to gain insights and optimize patient care.

“Oleksiy (PathToProject) and I worked together on a Digital Transformation project for Bayer LATAM Radiología. Oly was the Drupal developer, and I was the business lead. His professionalism, technical expertise, and ability to deliver functional improvements were some of the key attributes he brought to the project. I also want to highlight his collaboration and flexibility—throughout the entire journey, Oleksiy exceeded my expectations. It’s great when you can partner with vendors you trust, and who go the extra mile. ”

Axel Gleizerman CopelloBuilding in the MedTech Space | Antler

“Oleksiy (PathToProject) is a great professional with solid experience in Drupal. He is reliable, hard-working, and responsive. He dealt with high organizational complexity seamlessly. He was also very positive and made teamwork easy. It was a pleasure working with him. ”

Oriol BesAI & Innovation (Discovery, Strategy, Deployment, Scouting) for Business Leaders

\[05\]

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

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