# Sitecore to Drupal Migration: How to Map Workflow and Personalization Boundaries Before the Rebuild

Sep 15, 2022

By Oleksiy Kalinichenko

A Sitecore to Drupal migration can look straightforward when the program is framed as a page inventory and content transfer exercise. In practice, the real delivery risk often sits elsewhere: approval chains nobody documented, publishing exceptions built around organizational politics, and personalization logic tied to assumptions the future platform may not need to reproduce.

This article outlines the discovery work that should happen before rebuild planning hardens. It shows how migration teams can surface workflow logic, targeting dependencies, and editorial operating habits so the Drupal solution reflects actual business behavior rather than an incomplete model of the current estate.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20220915-sitecore-to-drupal-migration-workflow-and-personalization-boundaries "Summarize this page with ChatGPT")[](https://claude.ai/new?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20220915-sitecore-to-drupal-migration-workflow-and-personalization-boundaries "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%2F20220915-sitecore-to-drupal-migration-workflow-and-personalization-boundaries "Summarize this page with Gemini")[](https://x.com/i/grok?text=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20220915-sitecore-to-drupal-migration-workflow-and-personalization-boundaries "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%2F20220915-sitecore-to-drupal-migration-workflow-and-personalization-boundaries "Summarize this page with Perplexity")

![Blog: Sitecore to Drupal Migration: How to Map Workflow and Personalization Boundaries Before the Rebuild](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20220915-sitecore-to-drupal-migration-workflow-and-personalization-boundaries--cover)

Sitecore to Drupal migration planning often starts with the visible estate: templates, components, page counts, and content volumes. Those inputs matter, but they rarely explain why the current platform behaves the way it does.

For enterprise teams, the harder questions sit below the surface. Who approves what, and under which conditions? Which pages bypass normal review? Where does localization change the publishing path? Which personalization rules drive meaningful outcomes, and which ones survive only because the old platform made them possible? What do authors believe they need, even when those behaviors are really workarounds for legacy constraints?

If those questions are left unresolved, the migration program can drift into a dangerous pattern. Delivery estimates are built from content and component counts, while the operating model is discovered too late. That usually leads to scope churn, governance redesign under pressure, and debates about parity after build work is already underway.

A better approach is to treat workflow and personalization as discovery domains in their own right. The goal is not to replicate everything Sitecore does. The goal is to understand which business behaviors must survive, which can be simplified, and which should be retired as the organization moves to Drupal.

### Why page counts do not reveal migration complexity

A page inventory is useful for estimating migration effort, but it is a weak predictor of operational complexity.

Two sections of a Sitecore estate may each contain 500 pages and still represent very different migration challenges. One may follow a standard publishing route with clear ownership and low-risk content updates. The other may support multiple markets, regulated review, embargo-based publication, campaign coordination, and audience targeting layered across shared components.

When migration planning stays too close to page counts, several hidden dependencies are often missed:

*   workflow branching by content type, business unit, or region
*   exception handling for urgent updates or legal reviews
*   personalization rules embedded in components rather than pages
*   authoring conventions that exist outside formal workflow configuration
*   publishing coordination across content, media, navigation, and campaign timing
*   reporting expectations tied to legacy targeting behavior

This is why discovery should not ask only, "What content exists?" It should also ask, "What has to happen before this content can safely go live?" and "Why does this page behave differently for different audiences?"

In enterprise CMS replatforming, those process questions often determine the shape of the target architecture more than the raw number of assets being migrated.

### Discovering workflow states, approval paths, and publishing exceptions

Workflow mapping should begin with the understanding that the configured workflow is only part of the story. In many organizations, the formal states inside Sitecore tell you less than the practical route content takes through the business.

A reliable discovery process usually combines three lenses:

1.  **Platform configuration review** to identify states, roles, transitions, notifications, and permissions.
2.  **Editorial interviews** to understand how teams actually work, including manual checks outside the CMS.
3.  **Publishing observation** to capture edge cases, exceptions, and dependency timing.

The purpose is to build an operating model map, not just a feature list.

Key questions to document include:

*   What content types use workflow, and which do not?
*   Which states are truly meaningful versus rarely used?
*   Who can approve publication, and who can override it?
*   Where do legal, compliance, brand, or localization reviews enter the process?
*   What SLAs or timing expectations shape publishing behavior?
*   Which content needs scheduled release, staged rollout, or coordinated launch support?
*   What happens when urgent content must bypass the normal route?
*   Are there differences between corporate, regional, campaign, and product publishing paths?

It is also important to distinguish between **workflow logic** and **governance logic**. Teams often describe both as workflow, but they are not the same thing.

*   Workflow logic is what the platform enforces through states, permissions, and transitions.
*   Governance logic is what the organization expects through policy, review practices, and accountability.

That distinction matters during a Sitecore workflow migration assessment because some governance needs may be better handled in Drupal through permissions, moderation states, content ownership rules, editorial dashboards, or documented operating procedures rather than a one-to-one rebuild of legacy states. This is exactly where [Drupal content architecture](/services/drupal-content-architecture) decisions start to matter.

A practical output from this phase is a workflow matrix for each major content domain. For every content type or business area, document:

*   current states and transitions
*   business purpose of each state
*   required actors and approvers
*   exceptions and bypass conditions
*   downstream dependencies such as localization, QA, or campaign launch
*   recommendation to keep, simplify, replace, or retire in Drupal

That recommendation column is critical. Discovery should not stop at documentation. It should actively frame target-state decisions.

### Mapping personalization logic and deciding what should move

Personalization is another area where migration teams can overestimate parity requirements and underestimate design effort.

In Sitecore estates, personalization logic may sit across multiple layers: page variants, component rendering rules, audience segments, campaign context, geography, referral sources, user attributes, or custom integrations. Some of it may be strategically important. Some of it may be rarely reviewed. Some may no longer reflect how the organization measures digital experience success.

That is why a Sitecore personalization migration discussion should start with dependency mapping, not rebuild assumptions.

For each active personalization use case, teams should capture:

*   where the logic is applied: page, component, fragment, or campaign level
*   what signals are used to determine the experience
*   where those signals come from: CMS data, analytics, CRM, marketing automation, or custom services
*   who owns the rule and how often it is reviewed
*   what business outcome the rule is supposed to support
*   whether the rule is still active, trusted, and measurable
*   whether the target Drupal ecosystem will support the same decision model, or whether another tool should own it

This last point is especially important. Not all personalization should be rebuilt in Drupal, and not all existing Sitecore targeting deserves migration. In many enterprise environments, the right future-state answer is a split of responsibilities:

*   Drupal manages structured content, taxonomy, governance, and editorial assembly.
*   An external experimentation, analytics, CDP, or marketing platform may own audience logic and delivery decisions.
*   Some legacy rules may be retired because they create operational overhead without clear value.

A useful way to assess personalization candidates is to group them into categories:

*   **must preserve** because they support critical journeys or contractual needs
*   **redesign** because the business outcome matters but the current implementation is too platform-specific
*   **defer** because value exists but should not block core migration delivery
*   **retire** because the rule is unused, untrusted, or unsupported by the future operating model

This categorization helps prevent two costly mistakes: assuming full parity is required, or eliminating capabilities without understanding business impact.

### Separating true requirements from legacy platform habits

One of the most valuable outcomes of Drupal migration discovery is the ability to distinguish between a real business requirement and a habit formed around the old platform.

Teams often say they need the new CMS to work exactly as the old CMS works. Usually, that is not literally true. What they need is confidence that important controls, publishing responsibilities, and audience goals will still be met.

Legacy platform habits often show up in statements like:

*   "We need six approval states because that is how the current platform works."
*   "Authors must duplicate content in this way because that is how campaigns are managed today."
*   "Every targeted message must be assembled in the CMS."
*   "This team needs publisher access because they have always had it."

Those statements may be valid, but they should be tested.

A good discovery workshop reframes them into sharper questions:

*   What decision is each approval state actually protecting?
*   What risk appears if the process is simplified?
*   Is the duplication a true business need or a workaround for content model limitations?
*   Does targeting belong in editorial tooling, campaign tooling, or an external decision engine?
*   Which permissions are needed for accountability, and which are simply inherited from history?

This is where content architecture and governance architecture become central to the migration. If the current Sitecore estate encouraged fragmented content ownership, hard-coded exceptions, or duplicated authoring patterns, Drupal should not be designed to preserve those weaknesses by default.

Instead, the target-state design should be anchored in a few practical principles:

*   model content around reusable business entities, not page-shaped convenience structures
*   define editorial roles based on accountable responsibilities, not broad legacy access
*   use moderation and workflow to support important control points, not every historical handoff
*   keep personalization decisions close to the systems best equipped to evaluate audience context
*   document the operating model alongside the technical design so process is not lost again

### Designing Drupal alternatives for workflow, targeting, and governance

Once the current-state behaviors are understood, the next step is not to ask, "How do we reproduce Sitecore in Drupal?" It is to ask, "What combination of Drupal capabilities, integrations, and governance patterns best supports the future operating model?"

For workflow, Drupal design often involves decisions across several layers:

*   content types and editorial ownership boundaries
*   moderation states and transition rules
*   role and permission model
*   revision strategy and auditability expectations
*   scheduling and release management approach
*   multi-site or multi-market governance model

The right answer depends on organizational complexity. Some enterprises genuinely need differentiated moderation models by content domain or market. Others benefit from a smaller, consistent set of states with strong governance guidance around them.

For targeting and personalized experience design, Drupal alternatives may include:

*   structured taxonomy and metadata to support downstream audience decisions
*   modular content design so variants can be assembled without template sprawl
*   integration points with analytics, testing, or campaign platforms
*   controlled editorial fields for segmentation-relevant content attributes
*   clear ownership of where targeting decisions are made and measured

The architecture decision here is less about feature matching and more about boundary setting. Teams need to decide:

*   what Drupal must own directly
*   what another platform should own
*   what can be manual at launch and automated later
*   what should be intentionally removed to reduce complexity

That boundary definition is one of the strongest controls against scope expansion in enterprise CMS replatforming. Without it, every legacy behavior risks becoming an implied rebuild requirement.

A practical target-state design package should include:

*   workflow recommendations by content domain
*   permission and role model principles
*   personalization decision ownership map
*   integration assumptions and unresolved dependencies
*   authoring experience implications
*   governance policies that sit outside pure configuration
*   phased delivery recommendations for launch versus post-launch enhancement

Programs doing this well usually combine migration planning with a clearer [Drupal platform strategy](/services/drupal-platform-strategy) so architecture, governance, and operating model decisions stay aligned.

### Cutover implications when behavior changes across platforms

Even when the target design is sound, cutover can become difficult if teams underestimate the human and operational effect of behavior change.

A Sitecore to Drupal migration does not only move content. It changes how content is reviewed, who owns publication, where audience decisions are made, and how editors interpret control. Those shifts affect training, launch readiness, and production risk.

Common cutover issues include:

*   authors discovering late that approval routes have been simplified or reassigned
*   campaign teams expecting personalization rules that are now deferred or handled elsewhere
*   publishing teams lacking clarity on what replaces historical exception paths
*   regional teams losing confidence because local governance nuances were never captured
*   support teams treating operating-model changes as defects because they were not socialized early

To reduce this risk, cutover planning should include explicit behavior-change preparation.

That can mean:

*   documenting which Sitecore behaviors will not be reproduced and why
*   validating new approval and publishing paths with real business scenarios before launch
*   rehearsing urgent publication, rollback, and exception handling in Drupal
*   creating role-based training tied to actual tasks rather than generic CMS tours
*   aligning support teams on expected differences between legacy and target-state operations

If personalization changes are part of the migration, the launch plan should also state clearly:

*   which experiences will be live at launch
*   which targeting use cases are deferred
*   which systems own segmentation and decisioning after cutover
*   how performance and business impact will be evaluated in the new model

This level of operational transparency is often what separates a controlled migration from a platform go-live that immediately turns into a backlog of avoidable complaints. In practice, that kind of disciplined transition planning is a core part of [Sitecore to Drupal migration](/services/sitecore-to-drupal-migration) work.

### A discovery worksheet for migration teams

Before design and estimation are finalized, migration teams should be able to answer the following questions with evidence rather than assumptions.

**Workflow discovery**

*   What are the major content domains in scope?
*   What approval paths exist today for each domain?
*   Which states are mandatory, optional, or obsolete?
*   What exceptions occur regularly?
*   Which reviews happen in the CMS versus outside it?
*   What are the real publication risks the workflow is managing?

**Personalization discovery**

*   What active personalization use cases exist today?
*   Which rules are business-critical?
*   What data sources and integrations do they depend on?
*   Who owns and validates them?
*   What outcomes are they intended to influence?
*   Should each use case be preserved, redesigned, deferred, or retired?

**Editorial operating model**

*   Who creates, reviews, approves, and publishes each content type?
*   Where do regional or business-unit differences matter?
*   What permissions are essential versus historical?
*   What authoring pain points are actually content model problems?
*   What behaviors depend on undocumented tribal knowledge?

**Target-state decisioning**

*   What should Drupal own directly at launch?
*   What should be handled through integrations or adjacent platforms?
*   What can be simplified without unacceptable business risk?
*   What needs phased delivery?
*   What changes must be communicated before cutover?

A worksheet like this gives the program something more useful than a broad migration inventory. It creates a decision record that links legacy behavior to future-state architecture.

That is especially important for large organizations, where migration success depends as much on governance translation as on technical execution. Projects such as [UNCCD](/projects/unccd-united-nations-convention-to-combat-desertification) show how consolidation work benefits from making editorial workflows and governance explicit rather than implicit.

In the end, strong Sitecore to Drupal migration planning is not about promising perfect parity. It is about discovering what the business actually depends on, designing Drupal around those needs, and making deliberate choices about what should change. When workflow logic, personalization boundaries, and editorial assumptions are mapped early, the rebuild becomes more predictable, the target architecture becomes more coherent, and the migration team is far less likely to be surprised by the behaviors that matter most.

Tags: Drupal, Sitecore Migration, Workflow Mapping, Personalization, Enterprise CMS, Migration Planning

## Explore Drupal Migration Planning and Governance

These articles extend the migration discovery work in this post by showing how enterprise teams map dependencies, content models, permissions, and cutover risks before rebuild decisions harden. Together they add practical context for planning a Drupal move without carrying forward unnecessary legacy behavior.

[

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

[

![Drupal Editorial Permissions Architecture for Multi-Team Publishing: How Role Models Break at Enterprise Scale](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20230618-drupal-editorial-permissions-architecture-for-multi-team-publishing--cover?_a=BAVMn6ID0)

### Drupal Editorial Permissions Architecture for Multi-Team Publishing: How Role Models Break at Enterprise Scale

Jun 18, 2023

](/blog/20230618-drupal-editorial-permissions-architecture-for-multi-team-publishing)

[

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

[

![How to Audit Enterprise Content Models Before a CMS Migration](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20250916-how-to-audit-enterprise-content-models-before-a-cms-migration--cover?_a=BAVMn6ID0)

### How to Audit Enterprise Content Models Before a CMS Migration

Sep 16, 2025

](/blog/20250916-how-to-audit-enterprise-content-models-before-a-cms-migration)

## Explore Drupal Migration and Governance Services

This article is about uncovering workflow, approval, and personalization dependencies before a Sitecore to Drupal rebuild. The most relevant next step is support that turns those discovery findings into a migration plan, content model, and governance approach for the target Drupal platform. These services help teams preserve the business behaviors that matter while simplifying or retiring legacy patterns that no longer fit the new architecture.

[

### Sitecore to Drupal Migration Services

Content model mapping and automated migration pipelines

Learn More

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

### Drupal Content Architecture

Drupal content architecture design and editorial operating design

Learn More

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

### Drupal Governance Architecture

Drupal editorial workflow engineering and permissions model design

Learn More

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

### Drupal Migration

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

Learn More

](/services/drupal-migration)[

### Drupal Platform Strategy

Roadmaps, governance model design, and platform decision frameworks

Learn More

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

### Customer Data Governance

Stewardship, standards, and CDP data policy and controls

Learn More

](/services/customer-data-governance)

## Explore Migration and Governance Case Studies

These case studies show how complex content operations were uncovered, mapped, and stabilized before major platform changes. They are especially relevant for understanding workflow boundaries, editorial governance, multilingual delivery, and the tradeoffs involved in moving from legacy CMS behavior to a cleaner Drupal model.

\[01\]

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

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

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

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

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

\[06\]

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