# AEM Content Fragments vs Experience Fragments: What to Untangle Before a Drupal Migration

Jun 10, 2026

By Oleksiy Kalinichenko

AEM to Drupal migrations often slow down when teams treat Content Fragments and Experience Fragments as if they were the same kind of asset. They are not. One usually points toward **structured, reusable content**, while the other often reflects **assembled presentation and delivery decisions**.

Before migration plans solidify, teams need to separate those patterns, audit how fragments are actually used, and decide what belongs in Drupal content entities, reusable components, layout systems, or nowhere at all. This article outlines a practical way to do that without assuming Drupal should mirror every AEM construct one for one.

Summarize this page with AI

[](https://chat.openai.com/?q=Summarize%20this%20page%20for%20me%3A%20https%3A%2F%2Fwww.pathtoproject.com%2Fblog%2F20260610-aem-content-fragments-and-experience-fragments-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%2F20260610-aem-content-fragments-and-experience-fragments-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%2F20260610-aem-content-fragments-and-experience-fragments-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%2F20260610-aem-content-fragments-and-experience-fragments-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%2F20260610-aem-content-fragments-and-experience-fragments-before-drupal-migration "Summarize this page with Perplexity")

![Blog: AEM Content Fragments vs Experience Fragments: What to Untangle Before a Drupal Migration](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20260610-aem-content-fragments-and-experience-fragments-before-drupal-migration--cover)

AEM to Drupal migration planning gets harder when fragment usage is left as a vague category. Teams may say they have "a lot of fragments" and assume the migration path is simple: export them, import them, reconnect them, and move on.

In practice, fragment-heavy AEM estates usually hide several different problems:

*   structured content that should survive and become well-modeled Drupal entities
*   reusable presentation assemblies that should become component or layout patterns
*   local exceptions that should be simplified or retired
*   dependencies on localization, personalization, DAM references, or rollout logic that are easy to underestimate

If those patterns are not separated early, the migration scope becomes misleading. Content effort, frontend effort, QA effort, and governance effort all get blended together. That usually produces rework later, especially once authors, market teams, and platform owners start validating what actually has to work in Drupal.

For organizations managing enterprise web estates across multiple markets, business units, or governance layers, this distinction matters even more. The challenge is not only technical migration. It is deciding which reuse models still make sense and which ones exist because of historical platform constraints.

## Why fragment-heavy AEM estates confuse migration scope

A fragment-heavy AEM environment can look efficient from a distance. Reuse appears high. Content seems modular. Pages appear to be assembled from manageable building blocks.

But during migration discovery, the word "fragment" often covers very different things:

*   editorially governed content shared across channels
*   teaser or promo patterns assembled for page reuse
*   channel-specific renderings of the same message
*   page sections duplicated through rollout conventions
*   embedded references to media, tags, taxonomies, or product data
*   presentation shortcuts used to avoid changing templates

When all of that is counted together, teams may overestimate how much content is truly structured and reusable. They may also underestimate how much fragment behavior depends on surrounding page composition, inheritance, or authoring workflow.

That creates several planning risks.

First, content modeling gets distorted. Teams may design Drupal content types around exported AEM shapes instead of around business meaning, editorial ownership, and publishing needs.

Second, frontend scope gets blurred. A migration team may assume fragment rendering is a backend content concern, when in reality some fragments are tightly coupled to component variants, layout rules, or design system decisions.

Third, governance assumptions go unchallenged. Reuse in AEM may have grown from convenience rather than policy. When moved to Drupal unchanged, it can create unnecessary coupling between teams that should actually have more local autonomy.

The result is a migration plan that looks neat in spreadsheets but breaks down during implementation.

## Content Fragments and Experience Fragments are not the same migration problem

The most important planning move is to keep content structure and presentation structure explicitly separate.

In broad terms, **Content Fragments** are typically closer to structured editorial content. They often represent reusable content units that can be referenced across pages or channels and may include fields, variations, and relationships to other assets.

**Experience Fragments** are usually closer to assembled presentation. They often package content and layout together for reuse in specific delivery contexts such as banners, teasers, headers, campaign sections, or channel-oriented experiences.

That distinction matters because the target patterns in Drupal are usually different.

Content Fragments can often map toward:

*   Drupal content entities or custom entity patterns
*   well-defined content types
*   taxonomies or reference relationships
*   shared content blocks where governance truly requires centralized reuse

Experience Fragments can often map toward:

*   reusable Paragraphs or component-based content assemblies
*   block patterns or controlled component compositions
*   layout builder or templated section patterns
*   frontend-rendered design system patterns with editorial inputs

Sometimes an Experience Fragment should not be recreated as a reusable artifact at all. If it exists only because of a historical template limitation, the better migration decision may be to absorb that behavior into a cleaner page or component architecture.

Likewise, not every Content Fragment should become a standalone Drupal node. Some may be better represented as embedded component data, supporting entities, or normalized references depending on search, governance, workflow, and reuse expectations.

So the real question is not, "What is the Drupal equivalent of this fragment?" The better question is, "What business, editorial, and delivery role is this artifact performing today, and what is the simplest durable target model in Drupal?"

## How to audit fragment usage across pages, channels, and markets

A good fragment audit is not just an inventory export. It is a usage and dependency analysis.

Start by classifying fragments according to **role**, not only by AEM type. For each fragment or fragment family, try to capture:

*   what the artifact represents in business terms
*   who owns it editorially
*   where it appears
*   whether it is shared across markets or channels
*   whether its reuse is intentional or accidental
*   whether it carries structured content, presentation logic, or both
*   what upstream and downstream dependencies it has

A practical audit usually benefits from four lenses.

**1\. Reuse lens**

Ask how many pages, templates, locales, or channels use the fragment. But do not stop at count. A fragment reused on 200 pages through a legacy pattern may still be a poor candidate for one-to-one preservation if those pages should be remodeled anyway.

**2\. Governance lens**

Identify who can change the fragment and what happens when they do. If a central team updates one fragment and ten regional sites change unintentionally, the migration must account for that governance model. Drupal can support central reuse, but it should not inherit hidden coupling by default. This is often where [Drupal governance architecture](/services/drupal-governance-architecture) decisions become as important as the migration mechanics themselves.

**3\. Rendering lens**

Determine whether the fragment contains content only, or whether it relies on layout, styling conventions, component wrappers, or page-specific assumptions. This is where many Experience Fragment migrations become more expensive than expected.

**4\. Lifecycle lens**

Ask whether the fragment is still needed. Some fragments persist because they once served a campaign, a market launch, or an old page model. Migration is often the best moment to retire obsolete patterns rather than carry them forward.

In workshops, it can help to group findings into a simple matrix with columns such as:

*   fragment identifier or family
*   current purpose
*   authoring owner
*   reuse scope
*   structural complexity
*   presentation coupling
*   localization behavior
*   personalization dependency
*   recommended Drupal target
*   retirement candidate yes/no

This turns the audit into a decision tool rather than a catalog.

## Decision matrix: structured Drupal entities, Paragraphs/components, layout patterns, or retirement

Once fragment usage is clearer, migration teams can make more defensible target decisions.

Here is a practical decision framework.

**Choose structured Drupal entities when:**

*   the fragment represents a stable business object or editorial content unit
*   it needs metadata, workflow, revisioning, searchability, or API reuse
*   it is referenced from multiple contexts without depending on a specific layout
*   authors need confidence that the content can live independently of one page instance

Examples might include modular article summaries, product-related information units, expert profiles, location records, policy statements, or campaign-independent reusable messaging.

**Choose Paragraphs or reusable components when:**

*   the content is meaningful mainly within the context of a page or section
*   authoring benefits from flexible assembly
*   the pattern is repeatable, but not necessarily worthy of full standalone lifecycle management
*   the component has a clear schema and a design system equivalent

This is often the right destination for many fragment patterns that look reusable but are really componentized page building blocks.

**Choose layout or templated patterns when:**

*   the fragment’s main value comes from arrangement rather than from independent content identity
*   consistent page section composition matters more than standalone editorial reuse
*   the business wants controlled flexibility within a governed page framework

This is often the better answer for many Experience Fragment cases. What is being reused is not just content. It is a display pattern. In Drupal, that usually belongs in a layout or component composition model rather than in a standalone content repository construct.

**Choose retirement when:**

*   the fragment supports a no-longer-relevant page model
*   it duplicates other content and creates governance confusion
*   it exists only to work around limitations that will not exist in the new platform
*   ownership is unclear and no future use case justifies migration effort

Retirement decisions are often the most valuable outcome of the audit. They reduce migration volume and improve the long-term clarity of the target architecture.

A useful principle is this: **model for future operations, not for historical equivalence**. Drupal should reflect the publishing model the organization wants to run, not preserve every artifact inherited from AEM. That usually requires deliberate [Drupal content architecture](/services/drupal-content-architecture) work rather than a direct export-import mindset.

## Dependency traps: localization, personalization, DAM references, and rollout assumptions

Fragment migration problems rarely come from the fragment alone. They come from what the fragment depends on.

Localization is one of the most common traps. A fragment may appear global, but in practice it may have local overrides, market-specific variations, language fallbacks, or rollout-driven inheritance rules. If those rules are not documented, teams can wrongly classify a fragment as centralized content when it is actually a governed localization pattern.

Before mapping fragments into Drupal, clarify:

*   whether translation is field-level or entity-level in practice
*   whether markets inherit, fork, or override shared content
*   which changes must propagate centrally and which must remain local
*   how fallback behavior should work in the target environment

Personalization is another common issue. Some fragment usage may be tied to audience segments, campaigns, authentication state, geography, or channel-specific delivery. If a fragment only makes sense when paired with targeting logic, treating it as plain content during migration will lead to incomplete requirements.

Similarly, DAM references should be audited with care. Content Fragments may reference images, documents, or media collections that carry their own metadata, permissions, renditions, and lifecycle rules. The migration plan needs to know whether those assets are moving to Drupal-managed media, an external DAM, or a hybrid pattern. Otherwise, teams discover late that "content migration" quietly included complex media dependency work.

Rollout assumptions can be even harder to spot. In large enterprise estates, some fragment reuse is embedded inside blueprint or inheritance structures. Authors may think they are editing local content while actually participating in a broader propagation model. If the new Drupal architecture will not replicate that inheritance behavior exactly, the migration must define a new governance model deliberately rather than accidentally.

This is where solution architects and content strategists need to work together. The right answer is often not to reproduce hidden dependency chains, but to expose and simplify them.

## Validation and cutover implications for fragment-driven content

Fragment disentangling is not only an architecture exercise. It changes how validation and cutover should be planned.

If fragments have been separated into structured content, reusable components, layout patterns, and retirement candidates, then testing should reflect those categories.

For structured content targets, validate:

*   field integrity and required relationships
*   editorial workflow behavior
*   search and listing behavior where relevant
*   API output if the content supports multiple channels

For component or Paragraph-based targets, validate:

*   authoring usability
*   component schema consistency
*   rendering across responsive breakpoints
*   behavior when optional fields are missing or varied

For layout-driven replacements of Experience Fragments, validate:

*   pattern consistency across templates and page types
*   content-editor constraints and freedoms
*   design system alignment
*   page assembly rules under realistic publishing scenarios

For retired patterns, validate that nothing mission-critical was silently removed. Retirement needs sign-off, not just omission.

Cutover planning also changes when fragment assumptions are made explicit. Teams can stage migration in more manageable tracks:

*   foundational content entities first
*   component and layout implementation next
*   market or channel-specific variations after core patterns are stable
*   final cleanup of low-value or obsolete fragment families before launch

This usually produces a more reliable path than trying to migrate all fragment artifacts as a single workstream. A structured [AEM to Drupal migration](/services/aem-to-drupal-migration) approach is usually what keeps those tracks aligned across modeling, implementation, and validation.

It also improves stakeholder communication. Business owners can review the future operating model in understandable terms: what is centrally managed, what is assembled per page, what is localized, and what is no longer needed.

## A migration readiness checklist for fragment disentangling

Before migration planning hardens, teams should be able to answer the following questions with reasonable confidence.

*   Have we separated Content Fragment use cases from Experience Fragment use cases based on role, not just platform labels?
*   Do we know which artifacts represent structured content and which represent presentation assemblies?
*   Have we identified fragment families that are shared across pages, channels, brands, or markets?
*   Do we understand the governance model behind that reuse?
*   Have we documented localization, variation, and override behavior?
*   Have we identified personalization or targeting dependencies?
*   Do we know which fragments rely on DAM assets or external data relationships?
*   Have we classified likely Drupal targets: entity, component, layout pattern, or retirement?
*   Have authors and business owners reviewed those target decisions?
*   Does the validation plan reflect the different migration paths for content, components, layouts, and decommissioned patterns?

If too many of these answers are still unclear, the migration is not yet ready for detailed estimation or delivery sequencing.

That may feel slow in the short term, but it prevents a much more expensive problem later: discovering mid-build that the team was never migrating a single thing called "fragments" in the first place.

## Final perspective

AEM fragment usage can carry real value. It may reflect years of effort to introduce reuse, consistency, and multi-channel flexibility into a large digital estate. But that value only transfers well when the underlying patterns are understood.

For **AEM Content Fragments to Drupal migration** planning, the key is not to search for one-to-one replacements. It is to decompose what fragments are doing today and rebuild those responsibilities in the right Drupal constructs.

Some patterns should become structured Drupal content. Some should become reusable components. Some should become governed layout patterns. Some should be retired without regret.

That is the untangling work that makes downstream architecture, estimation, implementation, and validation more reliable.

For enterprise teams approaching **AEM to Drupal migration planning**, this is often the point where the migration stops being a file transfer exercise and starts becoming a platform design decision. That is also where better outcomes usually begin, especially when teams treat it as a target-state architecture problem rather than just a content extraction exercise, as seen in large-scale [Drupal DXP modernization](/projects/copernicus-marine-service-environmental-science-marine-data).

Tags: Drupal, AEM to Drupal migration, AEM Content Fragments to Drupal migration, AEM Experience Fragments migration, Drupal content architecture, Enterprise CMS migration

## Explore AEM Migration Dependencies and Governance

These articles extend the same migration-planning lens by unpacking the hidden dependencies, inheritance rules, and media or workflow behaviors that often sit behind AEM content structures. Together they help teams separate what should be modeled in Drupal from what should be simplified, remapped, or retired during the move.

[

![AEM Live Copy and Rollout Governance Before Drupal Migration](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260604-aem-live-copy-rollout-governance-before-drupal-migration--cover?_a=BAVMn6ID0)

### AEM Live Copy and Rollout Governance Before Drupal Migration

Jun 4, 2026

](/blog/20260604-aem-live-copy-rollout-governance-before-drupal-migration)

[

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

## Explore Drupal Migration Services

This article is about untangling AEM fragment patterns before a Drupal move, so the most relevant next step is help with migration planning and content model design. These services support the discovery, mapping, and implementation work needed to separate structured content from presentation-heavy fragments and carry that into Drupal cleanly. They also cover the broader replatforming and modernization decisions that keep the migration maintainable after launch.

[

### AEM to Drupal Migration Services

Content and integration migration with controlled cutover

Learn More

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

### Drupal Content Architecture

Drupal content architecture design and editorial operating design

Learn More

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

### Drupal Migration

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

Learn More

](/services/drupal-migration)[

### Drupal Data Architecture

Entity modeling and durable data structures

Learn More

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

### Drupal Governance Architecture

Drupal editorial workflow engineering and permissions model design

Learn More

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

### Drupal Platform Audit

Enterprise Drupal Technical Assessment & Drupal Health Check

Learn More

](/services/drupal-platform-audit)

## Explore Drupal Migration and Content Governance

These case studies show how complex content structures were audited, simplified, and rebuilt for long-term maintainability during platform change. They are especially relevant for teams separating structured content from presentation-heavy patterns before moving from AEM to Drupal. Together, they illustrate migration planning, governance, and component-based delivery in practice.

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

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