# AEM Translation Project and Language Copy Audits Before Drupal Migration: The Localization Logic That Rebuilds Complexity if You Ignore It

Jan 16, 2024

By Oleksiy Kalinichenko

AEM to Drupal migrations often treat localization as a content export task when it is really an architecture and operating-model decision. This article explains how to audit **translation projects**, **language-copy behavior**, **fallback assumptions**, and **market-specific exceptions** before you define the Drupal target model, so multilingual delivery does not fail after launch.

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%2F20240116-aem-translation-project-and-language-copy-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%2F20240116-aem-translation-project-and-language-copy-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%2F20240116-aem-translation-project-and-language-copy-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%2F20240116-aem-translation-project-and-language-copy-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%2F20240116-aem-translation-project-and-language-copy-audit-before-drupal-migration "Summarize this page with Perplexity")

![Blog: AEM Translation Project and Language Copy Audits Before Drupal Migration: The Localization Logic That Rebuilds Complexity if You Ignore It](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20240116-aem-translation-project-and-language-copy-audit-before-drupal-migration--cover)

Localization problems in CMS migrations rarely start with missing translated text. They usually start with hidden operating rules.

In AEM, teams can live for years with a mix of translation projects, language branches, inherited content patterns, manual market overrides, and approval timing that only makes sense because the current platform evolved around them. When migration planning begins, those behaviors are often collapsed into a simplified assumption: export the pages, move the languages, reconnect translation later.

That assumption is risky.

AEM to Drupal localization migration is not just about moving multilingual content. It is about discovering how regional sites are actually maintained, where teams depend on inheritance, when translations are triggered, which exceptions are accepted as business policy, and which legacy patterns should not survive the move.

If that discovery happens too late, the target platform can be forced to recreate accidental complexity. If it happens early, the migration team can make explicit decisions about what to preserve, simplify, or retire.

## Why localization behavior is often discovered too late in AEM migrations

Localization is frequently treated as a downstream workstream because it sits between content architecture, publishing operations, and market governance. That makes it easy to underestimate during early scoping.

Several patterns contribute to the delay:

*   Core migration discussions often focus first on templates, components, integrations, and content volume.
*   Market sites may look structurally similar on the surface while behaving very differently in day-to-day operations.
*   Translation ownership is often split across platform teams, local editors, agencies, and regional approvers.
*   Exception handling may be documented in spreadsheets or tribal knowledge rather than in formal system rules.
*   Teams may assume that if a language tree exists, the operating model behind it is already understood.

The result is predictable. A target Drupal model gets drafted around neat assumptions about source and translated content, only for the team to discover later that some markets inherit most content, some duplicate selectively, some delay publication until regulatory review, and some intentionally diverge from global source content for long periods.

That is why an **[AEM translation audit before Drupal migration](/services/aem-to-drupal-migration)** should be treated as a readiness activity, not a cleanup task.

## Translation projects, language copies, and rollout assumptions to inventory

A useful audit should not begin by asking, "How many languages do we have?" It should begin by asking, "How does multilingual content actually move, change, and get approved today?"

In practice, the discovery work usually needs to inventory several layers.

### 1\. Language structure and content relationships

Start with the observable structure:

*   Which languages and regions exist in AEM?
*   Are there country-specific variants within the same language?
*   Which branches are complete sites versus partial localized sections?
*   Which content types appear in all markets, and which are selectively localized?
*   Where are shared patterns consistent, and where have markets created unique structures?

This creates a baseline, but it is only the first layer. Structure alone does not explain behavior.

### 2\. Translation initiation rules

Next, identify how translation work begins:

*   What triggers translation requests?
*   Are translation projects created automatically, manually, or through mixed practices?
*   Are all content changes sent for translation, or only selected fields and page types?
*   Is there a business threshold for "translation-worthy" updates?
*   Who decides whether a market receives an update at all?

These rules matter because Drupal workflows should reflect the real operating model, not an idealized one that no team follows.

### 3\. Inheritance and divergence behavior

AEM language-copy usage often creates assumptions about what is shared and what is market-owned. Audit those assumptions explicitly:

*   Which content elements are expected to stay synchronized across markets?
*   Which elements are commonly overridden locally?
*   How long can a local override remain in place before it is reviewed?
*   Are there content sections that begin as inherited and later become permanently local?
*   Are there components where only part of the content is translated while other fields remain global?

This is where hidden complexity usually appears. A market may seem to have a translated page, but operationally it may depend on a combination of inherited source content, manual edits, untranslated utility fields, and delayed approvals.

### 4\. Workflow and approval timing

Translation delivery is not complete when the translated text returns. It is complete when content is reviewed, approved, and published according to market policy.

Inventory:

*   Who approves translated content?
*   Are approvals centralized or market-specific?
*   Are legal, regulatory, or brand reviews part of the process?
*   Can translated content publish automatically, or does it wait for human review?
*   Do some markets intentionally publish later than the source market?

A migration that ignores timing rules may technically preserve content but still break launch coordination and governance.

### 5\. Fallback assumptions

Fallback logic is often more important than teams realize.

For example:

*   If a translation does not exist, what is shown or published today?
*   Is source-language content temporarily acceptable in some markets but prohibited in others?
*   Are missing page fragments, labels, or metadata handled differently from body content?
*   Do operational teams rely on manual fallback decisions rather than platform-enforced behavior?

Drupal can support multilingual content models and workflows, but the target design should be based on validated business rules, not vague expectations that "the platform will handle fallback."

## Questions that expose hidden market-specific exceptions

The most valuable audit output often comes from the questions that reveal where standards are not actually standard.

Here are the kinds of questions that tend to surface real delivery risk:

*   Which markets are allowed to reject global content and write their own version?
*   Which page types are translated everywhere, and which are optional by region?
*   Where do local teams change content after translation without routing updates back to central teams?
*   Which markets require local legal or compliance review before publication?
*   Are there pages that should inherit global updates automatically except for a few locked fields?
*   Which taxonomies, labels, CTAs, disclaimers, or SEO fields are maintained centrally versus locally?
*   What happens when source content changes after a local market has already customized its version?
*   Are there seasonal campaigns or product launches that temporarily suspend normal translation workflow?
*   How are urgent corrections handled across languages when the normal process is too slow?
*   Which localization rules are policy, and which exist only because AEM made them convenient?

These questions help separate three different realities that teams often blend together:

1.  **Required business behavior** that must survive migration.
2.  **Legacy accommodation** that can be redesigned more cleanly.
3.  **Accidental complexity** that should be retired rather than rebuilt.

That distinction is central to effective multilingual Drupal migration planning.

## Mapping AEM localization behavior to Drupal content models and workflows

Once the source behavior is understood, the next step is not to replicate AEM terminology inside Drupal. It is to translate business needs into target-platform concepts with as little unnecessary complexity as possible.

A practical mapping exercise usually covers four domains.

### Content model mapping

For each multilingual content type, define:

*   What constitutes the source version
*   Which fields are translatable n- Which fields remain shared or centrally managed
*   Whether regional variants are true translations or independent localized content
*   How taxonomy, metadata, labels, and reusable content elements should behave across languages

This is where many migrations either over-normalize or over-customize.

If every market exception is modeled as a permanent structural rule, Drupal becomes unnecessarily complex. If true regional independence is ignored, editors end up fighting the platform.

### Editorial workflow mapping

Map current-state translation and approval behavior into target workflows:

*   Creation of source content
*   Translation request or handoff step
*   Returned translation review
*   Market approval
*   Publish readiness
*   Exception or rework path

The important point is not to chase one-for-one module parity with AEM behavior. The goal is to create a Drupal workflow model that supports real operating needs while removing avoidable friction.

### Governance mapping

Clarify ownership in the target state:

*   Who can create source content?
*   Who can request translation?
*   Who can edit localized variants?
*   Who can override shared messaging?
*   Who approves country-specific exceptions?

Without this governance layer, even a clean multilingual content model can degrade quickly after launch.

### Fallback and publishing policy mapping

Document explicit target-state rules for:

*   Missing translations
*   Partially translated content
*   Delayed market publication
*   Reuse of source-language content where allowed
*   Rollback behavior when localized content is incomplete or invalid

This is especially important because many fallback assumptions in legacy platforms are not consistently understood by stakeholders. Migration is the right moment to make them visible and intentional.

## Where teams should preserve, simplify, or retire legacy patterns

Not every localization pattern in AEM deserves to be migrated.

A strong audit should produce decision-oriented outputs, not just documentation. A useful framework is to classify each significant behavior into one of three buckets.

### Preserve

Preserve patterns that represent genuine business requirements, such as:

*   mandatory local approval before publication
*   region-specific legal copy ownership
*   selective market participation in certain content programs
*   controlled divergence for regulated or commercially distinct markets

These are operating requirements. If they disappear in Drupal, the migration will create business risk.

### Simplify

Simplify patterns that are real but over-engineered in the current platform, such as:

*   too many manual checkpoints for routine translation updates
*   inconsistent handling of shared fields across markets
*   unnecessary branching for markets that rarely diverge
*   duplicate editorial steps created by historical tooling constraints

Simplification can reduce training burden, shorten publishing cycles, and make localization behavior easier to support.

### Retire

Retire patterns that persist only because nobody challenged them, such as:

*   dormant language structures no longer maintained
*   exceptions that apply to one old campaign but still shape architecture
*   translation routing rules that depend on outdated team structures
*   market branches that exist as technical leftovers rather than active operating entities

This is where migration creates strategic value. [AEM to Drupal migration services](/services/aem-to-drupal-migration) should not become a mechanism for preserving every old compromise.

## Validation and cutover considerations for multilingual launches

Even a well-designed target model can fail if validation only checks page presence and rendered text.

Multilingual launch readiness should test behavior, not just migrated content.

### Validate representative scenarios

Build test cases around realistic operating patterns, for example:

*   a new source page translated into multiple markets
*   a late source update after one market has already localized and approved content
*   a market-specific override that should remain intact during subsequent global changes
*   a missing translation scenario with an agreed fallback policy
*   delayed publication for one region while other locales go live

These tests reveal whether the target workflows and content relationships match the intended business model.

### Validate governance and handoffs

Confirm that real users can execute the process:

*   central authors
*   localization managers
*   translators or external translation coordinators
*   regional reviewers
*   publishers

A workflow that looks correct in architecture diagrams may still fail in practice if ownership is unclear or approvals do not align with how teams operate.

### Validate content completeness rules

Teams should agree on what "ready" means for multilingual launch. That can include:

*   required translated fields by content type
*   mandatory metadata and SEO fields
*   required review status before publish
*   allowed exceptions for untranslated content
*   escalation paths for blocked markets

Without clear readiness criteria, cutover decisions become inconsistent and risky.

### Plan cutover with market nuance

Not every locale needs the same migration approach at the same time.

Some markets may be suitable for direct cutover because their localization patterns are simple and standardized. Others may need phased onboarding, temporary manual controls, or additional editorial support because their divergence from global content is higher.

That is why multilingual cutover planning should be informed by the audit outputs, not bolted on after the target architecture is finalized.

## The audit deliverables that make migration decisions clearer

To be useful, a translation workflow audit should produce artifacts the migration team can act on.

Typical outputs include:

*   a language and market inventory
*   a matrix of content types and translatable fields
*   a map of shared, inherited, and locally owned content behavior
*   current-state workflow diagrams for translation and approval
*   a list of fallback assumptions and exception cases
*   a preserve/simplify/retire recommendation set
*   target-state implications for Drupal content modeling and editorial workflow design
*   launch validation scenarios for multilingual QA

These outputs create alignment between architecture, editorial operations, and delivery planning. Just as importantly, they reduce the chance that localization complexity will be rediscovered late in build or after go-live.

## Final thought

The biggest localization risk in an AEM to Drupal migration is not usually missing translated assets or incomplete exports. It is carrying forward undocumented behavior without deciding whether it should exist in the future.

Translation projects, language-copy patterns, market inheritance, and approval timing often encode years of business decisions, exceptions, and workarounds. If those rules are not audited early, the Drupal solution can end up recreating complexity by accident. If they are audited early, the migration becomes an opportunity to build a multilingual operating model that is clearer, leaner, and easier to govern.

That is why localization discovery should be treated as a [migration-readiness workstream](/services/drupal-platform-strategy) in its own right. It gives teams the basis to preserve what matters, simplify what does not, and launch multilingual experiences with fewer surprises.

Tags: Drupal, AEM Migration, Localization, Multilingual CMS, Enterprise CMS

## Explore AEM to Drupal Migration Governance

These articles extend the same migration-planning lens into other hidden operating rules that can break a Drupal move. Together they cover permissions, personalization, live copy inheritance, workflow automation, and cutover controls so you can map what should be preserved, simplified, or retired before launch.

[

![AEM Permission and Group Model Audits Before Drupal Migration: The Access Logic That Quietly Rebuilds Editorial Risk](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20221018-aem-permission-and-group-model-audit-before-drupal-migration--cover?_a=BAVMn6DY0)

### AEM Permission and Group Model Audits Before Drupal Migration: The Access Logic That Quietly Rebuilds Editorial Risk

Oct 18, 2022

](/blog/20221018-aem-permission-and-group-model-audit-before-drupal-migration)

[

![AEM Personalization and ContextHub Audits Before Drupal Migration: What to Rebuild, Replace, or Retire](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20230912-aem-personalization-and-contexthub-audit-before-drupal-migration--cover?_a=BAVMn6DY0)

### AEM Personalization and ContextHub Audits Before Drupal Migration: What to Rebuild, Replace, or Retire

Sep 12, 2023

](/blog/20230912-aem-personalization-and-contexthub-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=BAVMn6DY0)

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

Jun 4, 2026

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

[

![AEM Workflow Launcher Audits Before Drupal Migration: The Automation Layer That Quietly Recreates Legacy Complexity](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_1440,h_1080,g_auto/f_auto/q_auto/v1/blog-20260622-aem-workflow-launcher-audit-before-drupal-migration--cover?_a=BAVMn6DY0)

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

Jun 22, 2026

](/blog/20260622-aem-workflow-launcher-audit-before-drupal-migration)

[

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

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

## Explore Drupal Migration and Content Architecture

This article is about uncovering localization behavior before an AEM to Drupal move, so the most relevant next step is help with migration planning and the Drupal target model. These services support content mapping, multilingual structure, governance, and the implementation work needed to preserve or simplify complex regional publishing rules. They are a strong fit if you want to turn audit findings into a migration plan that will hold up 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 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 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 Multilingual Migration and Governance

These case studies show how multilingual content, governance rules, and platform structure were handled in real delivery work before or during major CMS change. They help contextualize the localization audit mindset by showing how teams preserved, simplified, or reworked complex operating models across regions and content workflows.

\[01\]

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

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

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

Industry: Food & Beverage / Consumer Goods

Business Need:

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

Challenges & Solution:

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

Outcome:

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

\[02\]

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

\[03\]

### [Copernicus Marine ServiceCopernicus Marine Service Drupal DXP case study — Marine data portal modernization](/projects/copernicus-marine-service-environmental-science-marine-data "Copernicus Marine Service")

[![Project: Copernicus Marine Service](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-copernicus--challenge--01)](/projects/copernicus-marine-service-environmental-science-marine-data "Copernicus Marine Service")

[Learn More](/projects/copernicus-marine-service-environmental-science-marine-data "Learn More: Copernicus Marine Service")

Industry: Environmental Science / Marine Data

Business Need:

The existing marine data portal relied on three unaligned WordPress installations and embedded PHP code, creating inefficiencies and risks in content management and usability.

Challenges & Solution:

*   Migrated three legacy WordPress sites and a Drupal 7 site to a unified Drupal-based platform. - Replaced risky PHP fragments with configurable Drupal components. - Improved information architecture and user experience for data exploration. - Implemented integrations: Solr search, SSO (SAML), and enhanced analytics tracking.

Outcome:

The new Drupal DXP streamlined content operations and improved accessibility, offering scientists and businesses a more efficient gateway to marine data services.

“Oleksiy (PathToProject) is demanding and responsive. Comfortable with an Agile approach and strong technical skills, I appreciate the way he challenges stories and features to clarify specifications before and during sprints. ”

Olivier RitlewskiIngénieur Logiciel chez EPAM Systems

\[04\]

### [JYSKGlobal Retail DXP & CDP Transformation](/projects/jysk-global-retail-dxp-cdp-transformation "JYSK")

[![Project: JYSK](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-jysk--challenge--01)](/projects/jysk-global-retail-dxp-cdp-transformation "JYSK")

[Learn More](/projects/jysk-global-retail-dxp-cdp-transformation "Learn More: JYSK")

Industry: Retail / E-Commerce

Business Need:

JYSK required a robust retail Digital Experience Platform (DXP) integrated with a Customer Data Platform (CDP) to enable data-driven design decisions, enhance user engagement, and streamline content updates across more than 25 local markets.

Challenges & Solution:

*   Streamlined workflows for faster creative updates. - CDP integration for a retail platform to enable deeper customer insights. - Data-driven design optimizations to boost engagement and conversions. - Consistent UI across Drupal and React micro apps to support fast delivery at scale.

Outcome:

The modernized platform empowered JYSK’s marketing and content teams with real-time insights and modern workflows, leading to stronger engagement, higher conversions, and a scalable global platform.

“Oleksiy (PathToProject) worked with me on a specific project over a period of three months. He took full ownership of the project and successfully led it to completion with minimal initial information. His technical skills are unquestionably top-tier, and working with him was a pleasure. I would gladly collaborate with Oleksiy again at any opportunity. ”

Nikolaj Stockholm NielsenStrategic Hands-On CTO | E-Commerce Growth

\[05\]

### [United Nations Convention to Combat Desertification (UNCCD)United Nations website migration to a unified Drupal DXP](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[![Project: United Nations Convention to Combat Desertification (UNCCD)](https://res.cloudinary.com/dywr7uhyq/image/upload/w_644,f_avif,q_auto:good/v1/project-unccd--challenge--01)](/projects/unccd-united-nations-convention-to-combat-desertification "United Nations Convention to Combat Desertification (UNCCD)")

[Learn More](/projects/unccd-united-nations-convention-to-combat-desertification "Learn More: United Nations Convention to Combat Desertification (UNCCD)")

Industry: International Organization / Environmental Policy

Business Need:

UNCCD operated four separate websites (two WordPress, two Drupal), leading to inconsistencies in design, content management, and user experience. A unified, scalable solution was needed to support a large-scale CMS migration project and improve efficiency and usability.

Challenges & Solution:

*   Migrating all sites into a single, structured Drupal-based platform (government website Drupal DXP approach). - Implementing Storybook for a design system and consistency, reducing content development costs by 30–40%. - Managing input from 27 stakeholders while maintaining backend stability. - Integrating behavioral tracking, A/B testing, and optimizing performance for strong Google Lighthouse scores. - Converting Adobe InDesign assets into a fully functional web experience.

Outcome:

The modernization effort resulted in a cohesive, user-friendly, and scalable website, improving content management efficiency and long-term digital sustainability.

“It was my pleasure working with Oleksiy (PathToProject) on a new Drupal website. He is a true full-stack developer—the ideal mix of DevOps expertise, deep front-end knowledge, and the structured thinking of a senior back-end developer. He is well-organized and never lets anything slip. Oleksiy understands what needs to be done before being asked and can manage a project independently with minimal involvement from clients, product managers, or business analysts. One of the best consultants I’ve worked with so far. ”

Andrei MelisTechnical Lead at Eau de Web

\[06\]

### [VeoliaEnterprise Drupal Multisite Modernization (Acquia Site Factory, 200+ Sites)](/projects/veolia-environmental-services-sustainability "Veolia")

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

[Learn More](/projects/veolia-environmental-services-sustainability "Learn More: Veolia")

Industry: Environmental Services / Sustainability

Business Need:

With Drupal 7 reaching end-of-life, Veolia needed a Drupal 7 to Drupal 10 enterprise migration for its Acquia Site Factory multisite platform—preserving region-specific content and multilingual capabilities across more than 200 sites.

Challenges & Solution:

*   Supported Acquia Site Factory multisite architecture at enterprise scale (200+ sites). - Ported the installation profile from Drupal 7 to Drupal 10 while ensuring platform stability. - Delivered advanced configuration management strategy for safe incremental rollout across released sites. - Improved page loading speed by refactoring data fetching and caching strategies.

Outcome:

The platform was modernized into a stable, scalable multisite foundation with improved performance, maintainability, and long-term upgrade readiness.

“As Dev Team Lead on my project for 10 months, Oleksiy (PathToProject) demonstrated excellent technical skills and the ability to handle complex Drupal projects. His full-stack expertise is highly valuable. ”

Laurent PoinsignonDomain Delivery Manager Web at TotalEnergies

![Oleksiy (Oly) Kalinichenko](https://res.cloudinary.com/dywr7uhyq/image/upload/c_fill,w_200,h_200,g_center,f_avif,q_auto:good/v1/contant--oly)

### Oleksiy (Oly) Kalinichenko

#### CTO at PathToProject

[](https://www.linkedin.com/in/oleksiy-kalinichenko/ "LinkedIn: Oleksiy (Oly) Kalinichenko")

### Do you want to start a project?

Send