# AEM Workflow Launcher Audits Before Drupal Migration: The Automation Layer That Quietly Recreates Legacy Complexity

Jun 22, 2026

By Oleksiy Kalinichenko

AEM to Drupal migrations often underestimate the automation hidden behind workflow launchers, DAM processing, approvals, notifications, and exception handling. This article explains how to inventory that behavior, decide what belongs in Drupal, and avoid rebuilding accidental complexity under a new platform.

Need help applying this?

Talk through the article with an expert and turn the guidance into a practical next step.

Talk to an expert

Summarize this page with AI

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

![Blog: AEM Workflow Launcher Audits Before Drupal Migration: The Automation Layer That Quietly Recreates Legacy Complexity](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20260622-aem-workflow-launcher-audit-before-drupal-migration--cover)

When teams begin planning an [AEM to Drupal migration](/services/aem-to-drupal-migration), the first instinct is usually to measure what is visible: sites, templates, components, content models, assets, and integrations. That work matters, but it is rarely the full operational picture.

In many enterprise environments, a substantial part of day-to-day publishing behavior lives in automation. Workflow launchers, asset handling steps, approval paths, notifications, scheduled jobs, and exception routines can quietly shape how content moves, how teams collaborate, and how compliance expectations are enforced. If that layer is not audited early, migration scope can look smaller than it really is.

This is where an **AEM workflow launcher audit** becomes strategically important. The purpose is not to recreate AEM feature-for-feature inside Drupal. It is to understand what business outcomes the current automations support, which of those outcomes are still valuable, and what implementation approach makes sense in the target platform.

A disciplined audit helps migration teams avoid two common failures:

*   underestimating the effort required to preserve essential operational behavior
*   overengineering Drupal to mimic legacy processes that no longer deserve to exist

## Why visible content is not the full migration scope

A migration plan built only around content and presentation can miss the systems of behavior that make content operations function in practice.

For example, a page may appear to follow a simple editorial lifecycle, but behind that surface there may be automation that:

*   triggers review when metadata changes
*   routes assets for processing after upload
*   sends notifications to distribution teams
*   blocks publishing until required fields are present
*   launches scheduled expiry or archival actions
*   handles special cases for regulated or regional content

None of those patterns are obvious from a visual audit of the site. Yet each one can affect implementation estimates, governance design, user training, and cutover planning.

This matters because migration stakeholders often ask a deceptively simple question: "How much of the current platform are we actually moving?" If the answer is based only on pages, components, and data structures, the estimate is incomplete.

A more accurate answer includes:

*   visible digital experiences
*   editorial and operational workflows
*   asset processing behavior
*   background automations and scheduled jobs
*   exception handling and human intervention paths
*   dependencies on external systems and teams

That broader lens is what turns migration planning from a content inventory exercise into a platform transition strategy.

## Where AEM workflow launchers usually hide business logic

In enterprise AEM implementations, workflow launchers often become a practical place to attach business behavior to content or asset events. Over time, that can create an automation layer that is only partially documented and not always well understood outside the platform team.

Common areas where hidden logic can accumulate include:

*   **DAM ingestion and processing**: asset uploads may trigger metadata normalization, rendition-related steps, review tasks, rights checks, or downstream notifications.
*   **Approvals and publishing control**: content changes can launch review sequences, sign-off steps, or publish-precondition checks.
*   **Metadata-driven actions**: changes to taxonomy, ownership, dates, or compliance fields can start workflows with business consequences.
*   **Scheduled operations**: timed jobs may handle archival, expiry, reminders, republishing, cleanup, or synchronization activities.
*   **Exception management**: fallback tasks, retries, and manual intervention procedures may exist for edge cases that appear rarely but matter significantly.
*   **Cross-system coordination**: automated steps may notify or pass payloads to analytics, search, translation, legal review, marketing operations, or product information systems.

The important point is not that all automation is bad. Much of it may reflect real operational needs. The risk comes from treating all existing automation as equally necessary, equally healthy, and equally portable.

A workflow launcher that once solved a real business problem may now be compensating for an outdated content model, a retired process, or a team structure that no longer exists. Without an audit, those distinctions remain invisible.

## Audit method: triggers, payloads, actors, side effects, and failure handling

A useful audit should go beyond a simple list of workflows. The goal is to describe each automation path in a way that supports migration decisions.

A practical method is to document each automation against five core dimensions, plus business intent.

### 1\. Trigger

Identify what starts the automation.

Typical trigger categories include:

*   content creation or update
*   asset upload or metadata change
*   publish or unpublish events
*   scheduled or recurring execution
*   manual initiation by an editor or operator
*   system-to-system inbound event

The trigger definition helps the team understand whether the automation is event-driven, schedule-driven, or human-driven. That distinction affects how it may be designed in Drupal or surrounding services.

### 2\. Payload

Document what object or data the automation acts upon.

Questions to answer include:

*   Is the payload a page, content item, asset, folder, metadata record, or batch?
*   What fields or properties determine the path taken?
*   Does the process require related records or external reference data?
*   Is the automation sensitive to volume, file size, content type, or geography?

This is where many migration assumptions break down. An automation that appears simple may depend on metadata quality, naming conventions, folder structures, or implicit relationships that are not represented cleanly in the target model.

### 3\. Actors

Identify who or what participates.

Actors may include:

*   editors
*   approvers
*   brand or legal reviewers
*   DAM managers
*   operations teams
*   external systems
*   background processing services

Understanding actors reveals whether the automation is truly a system workflow, a people workflow, or a mixed operational process. That matters because Drupal may handle some parts natively through editorial workflow patterns, while other parts may be better implemented through integrations, queue-based processing, or operating procedures outside the CMS.

### 4\. Side effects

Document what the automation changes, creates, sends, or blocks.

Examples include:

*   changing status or ownership
*   generating derived outputs
*   sending notifications
*   updating metadata
*   invoking external APIs
*   writing logs or audit entries
*   creating tasks for human follow-up
*   preventing publication under certain conditions

Side effects often matter more than the workflow itself. If a launcher ultimately exists to ensure a policy check happens before publication, the migration team should design for that policy outcome rather than focus only on copying the trigger mechanism.

### 5\. Failure handling

Many migration plans ignore this until late in delivery, but failure behavior is often where business risk lives.

Document:

*   what happens when processing fails
*   whether retries exist
*   who gets notified
*   how exceptions are resolved
*   whether content is blocked, delayed, or allowed through
*   how teams know a problem occurred

A workflow that runs successfully 95 percent of the time may still create disproportionate risk if the remaining 5 percent involves legal content, critical assets, or homepage publication windows.

### 6\. Business intent

For each automation path, ask one simple question: **what business outcome is this trying to protect or enable?**

Possible answers might include:

*   maintaining metadata quality
*   enforcing review and compliance
*   accelerating editorial throughput
*   improving asset reuse
*   coordinating downstream distribution
*   reducing manual effort
*   preserving auditability

This field is essential because it gives architects permission to redesign. Once intent is clear, the team can evaluate multiple ways to satisfy it instead of assuming the current mechanism is mandatory.

A lightweight audit table often works well. Each row can represent one automation path, with columns for trigger, payload, actors, side effects, failure handling, business owner, frequency, and migration disposition.

## Separate useful automation from legacy residue

Once the inventory exists, the next step is classification. This is where teams decide what is valuable operational behavior versus what is simply inherited platform residue.

A practical classification model is:

*   **retain as a required capability**
*   **redesign for the target operating model**
*   **move outside the CMS**
*   **retire**

The distinction is important.

Some automation is business-critical but implemented inefficiently. That should not be retired; it should be redesigned.

Some automation looks important because it is complicated, but on review it may support a process nobody wants to preserve. That should not be migrated just because it exists.

A few useful decision questions:

*   Does this automation support a current policy, control, or service-level expectation?
*   Is there an active business owner who would defend its necessity?
*   Does it solve a platform limitation that will no longer exist after migration?
*   Has it become a workaround for weak governance or poor data quality?
*   Would a simpler content model or editorial policy eliminate the need?
*   Is the process frequency high enough to justify automation?
*   What happens if the behavior is removed entirely?

Teams should be especially cautious with automations that have one or more of these signals:

*   unclear ownership
*   no documented business rationale
*   highly conditional branching built up over years
*   dependence on obsolete organizational roles
*   brittle assumptions about repository structure or metadata conventions
*   low usage but high maintenance overhead

Those patterns often indicate accidental complexity rather than durable business need.

## Map each automation path to Drupal workflow, queues, integrations, or retirement

After classification, each automation path needs a target-state decision. This is where migration readiness improves dramatically, because the team stops speaking in generalities and starts expressing implementation intent.

For Drupal-oriented planning, it is useful to think in capability categories rather than one-to-one feature parity.

### Editorial workflow

If the core need is human review, state transitions, approval visibility, or publishing governance, the target pattern may be an editorial workflow approach inside Drupal.

This is most appropriate when:

*   the primary activity is content status management
*   human decision points are central
*   the process should be visible to editors
*   auditability and governance are part of content operations

The key is to model the necessary states and responsibilities without reproducing every historical branch unless there is a strong reason.

### Queue-based or asynchronous processing

If the core need is background handling of tasks, especially at scale, queue-oriented processing can be a better fit than trying to embed everything into direct editorial interactions.

This is often relevant for:

*   asset-related processing steps
*   bulk updates
*   deferred synchronization
*   long-running or failure-prone tasks
*   work that benefits from retries and operational monitoring

The benefit of this approach is not only scale. It also clarifies operational responsibility and makes failure handling more explicit.

### Integrations

Some automations do not belong primarily in the CMS at all. If the process is really about passing events or data between systems, Drupal may be the orchestration point, a participant, or simply the origin of a signal.

This can apply to:

*   notifications to collaboration tools or service desks
*   handoffs to asset services or product systems
*   review interactions with external stakeholders
*   downstream publishing or search indexing dependencies
*   translation or localization operations

In these cases, the right question is not "How do we rebuild the AEM launcher?" but "Where should this responsibility live in the new platform ecosystem?"

### Retirement

Some automations should end.

Retirement is appropriate when the path exists only because of historic constraints, duplicated controls, or obsolete operating assumptions. Explicit retirement decisions are valuable because they reduce cost and complexity, and they prevent old behaviors from silently reappearing in requirements workshops.

A good migration artifact includes a target-state mapping for each audited path, such as:

*   Drupal workflow
*   Drupal plus queue processing
*   integration-led solution
*   manual operational procedure
*   retired in target state

That output becomes much more actionable for solution design and estimation than a generic statement that workflows will be "handled later."

## Governance decisions before implementation estimates harden

The worst time to clarify automation behavior is after implementation estimates are already circulating as commitments.

Before estimates harden, governance stakeholders should align on several decisions.

### What level of editorial control is actually required?

Enterprise teams often inherit approval structures that are broader than necessary. Some are critical. Others persist because nobody has reset them. Migration is the right moment to determine which review gates are mandatory, which are optional, and which should be replaced by policy and training.

### Which failures must block publication?

Not every automation problem deserves the same treatment. A metadata enrichment issue may warrant a warning and follow-up task. A compliance approval failure may need to block release. These distinctions shape both technical design and operational playbooks.

### Who owns each automated outcome?

Every material automation path should have a business owner and an operational owner. Without that clarity, teams tend to implement behavior that nobody is prepared to govern after launch.

### What belongs inside Drupal versus in the surrounding delivery architecture?

This is a strategic architecture decision, not only a technical one. Keeping Drupal focused on content and editorial governance can improve maintainability, while offloading cross-system or heavy background processing to supporting services can improve resilience and transparency. In larger programs, this kind of boundary-setting often sits within broader [legacy CMS modernization](/services/legacy-cms-modernization) work rather than a narrow feature migration exercise.

### What evidence is needed for compliance or audit?

If the current automation contributes to traceability, review history, or operational evidence, those needs should be defined explicitly. Otherwise teams may accidentally remove important controls while simplifying workflows.

These governance decisions reduce rework because they resolve ambiguity before technical teams start translating every discovered launcher into a presumed implementation requirement.

## Validation and cutover checks for migrated automation

Even a strong audit and design process needs validation before go-live. Automation is one of the easiest areas to miss during migration testing because many behaviors occur outside obvious page rendering scenarios.

A useful validation plan should cover both functional and operational outcomes.

### Functional validation

Confirm that intended business outcomes still occur:

*   required approvals happen when expected
*   content state changes follow the agreed model
*   notifications reach the right actors
*   asset-related processing completes within acceptable timeframes
*   scheduled actions execute on the correct cadence
*   integration handoffs produce expected downstream results

### Negative and exception testing

Test what happens when things go wrong:

*   malformed or incomplete metadata
*   missing dependencies
*   large or unusual asset inputs
*   integration timeouts or failures
*   duplicate events
*   user actions taken out of expected sequence

This is where queue behavior, retry logic, and escalation processes should be exercised deliberately.

### Operational readiness

Check whether support teams can observe and manage the new behavior:

*   Are failures visible?
*   Are logs meaningful?
*   Do teams know who responds?
*   Are manual recovery steps documented?
*   Can business owners distinguish warning conditions from blocking incidents?

### Cutover-specific checks

At cutover, automation requires special attention because both source and target environments may be active in different ways for a period of time.

Confirm:

*   which source automations must be frozen or disabled
*   whether scheduled jobs could run in both environments
*   how in-flight approvals or tasks will be handled
*   how asset processing backlogs will be managed
*   whether integration endpoints are aligned to the target state

Without these checks, teams can end up with duplicate processing, missed approvals, or inconsistent records during transition. That is why [cutover planning and execution](/services/migration-to-drupal) should account for automation behavior explicitly, not just content transfer and page parity.

## A migration audit should reduce complexity, not preserve it

The value of an AEM workflow launcher audit is not simply better documentation. Its real value is architectural clarity.

By auditing triggers, payloads, actors, side effects, and failure handling, teams can see the difference between essential business capability and inherited implementation detail. That makes Drupal migration planning more accurate, governance discussions more concrete, and delivery estimates more defensible.

Most importantly, it prevents a common mistake: rebuilding old complexity under a new platform name.

A successful AEM to Drupal migration does not try to make Drupal behave like a direct clone of legacy automation. It identifies what the organization actually needs from workflow, asset handling, and operational control, then implements those needs using a target-state architecture that is simpler, clearer, and easier to govern.

If visible content tells you what the platform publishes, automation tells you how the organization really operates. For migration leads and architects, both layers need to be in scope from the start.

Tags: AEM workflow launcher audit, AEM to Drupal migration, AEM workflow audit, Drupal migration planning, enterprise CMS automation, DAM workflow migration, migration readiness, Drupal

## Explore AEM to Drupal Migration Audits

These articles extend the same migration-readiness lens by showing how hidden dependencies, content structures, media governance, and cutover behavior can reshape scope. Together they help you audit the operational layer before moving from AEM to Drupal so you preserve what matters without recreating legacy complexity.

[

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

### 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=BAVMn6B00)

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

[

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

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

Jun 4, 2026

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

[

![AEM Content Fragments vs Experience Fragments: What to Untangle Before a Drupal Migration](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260610-aem-content-fragments-and-experience-fragments-before-drupal-migration--cover?_a=BAVMn6B00)

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

Jun 10, 2026

](/blog/20260610-aem-content-fragments-and-experience-fragments-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=BAVMn6B00)

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

[

![Drupal Migration Validation Beyond Record Counts: How to Prove the Platform Still Works After Cutover](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20211007-drupal-migration-validation-beyond-record-counts--cover?_a=BAVMn6B00)

### Drupal Migration Validation Beyond Record Counts: How to Prove the Platform Still Works After Cutover

Oct 7, 2021

](/blog/20211007-drupal-migration-validation-beyond-record-counts)

## Explore Drupal Migration and Governance Services

This article is about uncovering hidden automation before moving from AEM to Drupal, so the most relevant next step is help with migration planning, content modeling, and platform governance. These services support the practical work of mapping legacy behavior into a Drupal target state without recreating unnecessary complexity. They also help teams validate scope, define operating rules, and execute a safer replatforming program.

[

### 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 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 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 Migration and Workflow Governance

These case studies show how complex content operations, automation, and governance were handled in real delivery work. They help frame what should be preserved, simplified, or rebuilt when moving from AEM to Drupal, especially where workflows, integrations, and editorial controls shape the platform beyond visible pages. Together they provide practical context for auditing legacy behavior before migration.

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

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

\[05\]

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