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

Oct 18, 2022

By Oleksiy Kalinichenko

AEM to Drupal migrations often focus early on content models, templates, components, and integrations. But many of the most consequential publishing risks sit somewhere less visible: inside AEM users, groups, inherited ACLs, approval paths, and the operational workarounds teams have built around them.

This article treats the **AEM permission audit before Drupal migration** as a core readiness workstream, not a late-stage security check. It outlines how to inventory access behavior, distinguish security controls from editorial operating rules, and translate those findings into Drupal roles, workflows, and governance boundaries that remain workable after go-live.

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%2F20221018-aem-permission-and-group-model-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%2F20221018-aem-permission-and-group-model-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%2F20221018-aem-permission-and-group-model-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%2F20221018-aem-permission-and-group-model-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%2F20221018-aem-permission-and-group-model-audit-before-drupal-migration "Summarize this page with Perplexity")

![Blog: AEM Permission and Group Model Audits Before Drupal Migration: The Access Logic That Quietly Rebuilds Editorial Risk](https://res.cloudinary.com/dywr7uhyq/image/upload/w_764,f_avif,q_auto:good/v1/blog-20221018-aem-permission-and-group-model-audit-before-drupal-migration--cover)

Content migrations from AEM to Drupal are rarely only about moving pages and components. In enterprise environments, access logic often carries just as much operational weight as the content itself.

Who can create content, who can edit it, who can approve it, who can publish to one region but not another, who can unlock urgent changes after hours, and who can override workflow friction during incidents: these patterns are usually not documented in one place. Instead, they are distributed across AEM groups, inherited permissions, workflow participation, folder structures, and years of local exceptions.

That is why an **AEM permission audit before Drupal migration** should be treated as a migration planning exercise. If teams postpone it until implementation or testing, they often discover too late that access behavior in the legacy platform encoded important organizational rules. Recreating those rules carelessly in Drupal can introduce editorial delays, excessive privilege, unclear ownership, or long-term governance debt.

A useful audit does not aim for perfect one-to-one parity. It aims to understand the business meaning of legacy access decisions, identify which rules still matter, and design a Drupal model that is secure, governable, and practical for future operations.

## Why permission models become migration risk late

Permission risk tends to appear late because it is easy to underestimate what access controls are doing in the current platform.

Early migration work usually centers on visible assets:

*   content structures
*   templates and components
*   taxonomy
*   integrations
*   authoring experience
*   publishing environments

Permissions seem, at first glance, like a mapping exercise to be handled nearer cutover. But that assumption breaks down in larger AEM estates.

In many enterprise CMS environments, permissions are not only enforcing security boundaries. They are also shaping editorial behavior. A group may exist not simply to grant read or write access, but to enforce a sequence of work between global brand, local market, compliance, and operations teams. An inherited ACL on a subtree may reflect regional ownership. A workflow participant group may indicate who is expected to approve regulated content. A broad exception granted to a support team may reveal recurring operational bottlenecks.

When these patterns are discovered late, teams face an unpleasant choice:

*   replicate legacy complexity in Drupal to preserve business continuity, or
*   simplify aggressively and risk breaking publishing operations

Neither option is attractive under deadline pressure.

Running the audit early changes the conversation. It gives architects and migration leads time to separate necessary controls from historical clutter, identify policy gaps, and define a cleaner target governance model.

## What to inventory in AEM users, groups, and inherited ACLs

An effective **AEM ACL audit** is not just a list of principals and permissions. It is an attempt to understand the relationship between technical access and real operating practice.

Start by collecting a structured inventory in several layers.

### 1\. User and identity patterns

At a high level, identify:

*   named users with elevated privileges
*   service or technical accounts relevant to publishing operations
*   external or federated identity patterns, where applicable
*   inactive or low-confidence accounts that may distort the current picture

The goal is not to preserve every account. The goal is to understand how much the current model depends on individuals rather than stable functional groups.

If publishing continuity relies on a handful of long-standing power users, that is an important migration risk. It usually suggests one of three things:

*   the group model is incomplete
*   workflow design has been bypassed in practice
*   operational support responsibilities are poorly formalized

### 2\. Group structure and naming logic

Next, review the **AEM group model migration** landscape.

Document:

*   top-level group hierarchy
*   nested groups and inheritance chains
*   names that imply business function, geography, brand, or environment
*   overlapping groups with nearly identical scopes
*   legacy groups that may no longer reflect current teams

Group names often contain institutional memory. Even when inconsistent, they can reveal how the organization thinks about ownership: by market, business unit, site family, content sensitivity, or operational function.

It is important to distinguish between groups that exist for identity administration convenience and groups that represent meaningful governance boundaries. Those are not always the same thing.

### 3\. Permission assignments and inheritance behavior

The access model in AEM frequently depends on where permissions are assigned and how they inherit down content structures.

Inventory should capture:

*   direct permission assignments to users or groups
*   inherited permissions on content subtrees
*   exceptions that break inheritance patterns
*   locations where permission structure mirrors site or organizational structure
*   areas with unusually broad or unusually fragmented access

This is where undocumented behavior often emerges. Two teams may appear to have the same publishing rights, but one relies on a clean inherited model while the other depends on a chain of exceptions accumulated over time.

Those differences matter when planning Drupal governance. A target model built only from headline roles can miss the practical subtleties that kept content operations functioning.

### 4\. Workflow participation and approval-related access

Permissions do not tell the whole story if workflow participation is treated separately.

Audit who can:

*   submit content for review
*   claim or act on workflow tasks
*   approve, reject, or request changes
*   publish directly outside normal review paths
*   perform emergency or operational overrides

In some AEM estates, workflow-related permissions reveal more about editorial governance than repository access alone. A technically broad editor role may still be tightly constrained in practice because approval rights are limited. In other estates, workflow may exist formally but be bypassed by users with broad publish access.

For migration planning, both conditions matter. You need to know not only what the model says, but how the organization actually ships content.

### 5\. Environment and operational boundaries

For enterprise programs, include environment-aware access distinctions where relevant.

Examples include:

*   authoring versus publishing responsibilities
*   production-only emergency privileges
*   regional operations teams with after-hours support access
*   shared services that can intervene across brands or markets

These boundaries often surface during cutover and support planning, so it is better to document them early rather than rediscover them during launch readiness.

## Separating security controls from editorial operating rules

A critical step in **editorial access migration planning** is separating what is fundamentally a security requirement from what is really an operating rule.

This distinction sounds simple, but it often decides whether the target Drupal model becomes manageable or brittle.

Security controls usually answer questions like:

*   Who should be prevented from accessing sensitive content or administration capabilities?
*   Which functions require least privilege?
*   Where must segregation of duties be enforced?
*   What access should be tightly restricted for compliance, risk, or operational integrity?

Editorial operating rules answer different questions:

*   Which team should act first in the publishing process?
*   When should local editors be able to modify shared content?
*   Who is responsible for review in a specific region or content domain?
*   Under what circumstances can urgent changes bypass normal queues?

In legacy AEM implementations, both kinds of rules can end up expressed through groups and permissions. That does not mean they should remain expressed the same way in Drupal.

For example, a permission pattern that blocks direct publishing for most editors may be serving a genuine control objective. But it may also be compensating for weak workflow design, unclear ownership, or historic limitations in team structure. If you migrate that pattern blindly, you may preserve the symptom rather than the intent.

A practical audit workshop should therefore classify each significant access rule into one of three categories:

*   **must preserve as a control**
*   **must preserve as an editorial outcome, but not necessarily via the same mechanism**
*   **candidate for simplification or retirement**

This classification helps prevent every legacy permission from being treated as equally important.

## Mapping AEM access behavior into Drupal roles and workflows

Once the audit is complete, the next task is not a direct permission translation table. It is a target operating model for **Drupal role mapping**.

Drupal roles and permissions can support a robust [governance framework](/services/drupal-governance-architecture), but they should be used intentionally. The migration team should begin with target-state behavior and then decide how roles, content-level ownership patterns, workflow states, and administrative boundaries work together.

A useful mapping process typically follows these steps.

### Define capability domains first

Before naming roles, define major capability domains such as:

*   content creation and editing
*   review and approval
*   publishing and release management
*   taxonomy or shared content administration
*   site configuration administration
*   media governance
*   regional or business-unit ownership
*   platform support and incident response

This prevents the design from collapsing too early into a long list of role labels copied from the source platform.

### Map business responsibilities, not just AEM groups

For each domain, ask:

*   What business responsibility does this access support?
*   Is the responsibility global, regional, local, or temporary?
*   Is it part of normal editorial work or platform administration?
*   Does it require role-based access, workflow state transitions, or both?

This is where **AEM to Drupal governance** becomes more than a technical conversion. The target model should reflect who owns decisions, not just who historically had access.

### Use workflow to express process where appropriate

Many legacy AEM permission patterns encode process indirectly. Drupal workflows can often carry part of that burden more clearly.

For example, if the business requirement is that local editors can draft and revise content but central brand must approve publication, the important outcome is not necessarily a complex set of tree-based permission exceptions. The important outcome is a controlled transition model with clear review responsibility.

That does not eliminate the need for permissions. It means permissions and workflow should be designed together instead of forcing all governance into one layer.

### Account for scope and ownership

Enterprise Drupal implementations often need access models that respect scope:

*   by brand
*   by region
*   by business unit
*   by content type or sensitivity
*   by platform function

During **CMS permission migration**, teams should define which distinctions genuinely need technical enforcement and which can be handled through workflow, operating policy, or content ownership conventions.

Not every organizational boundary deserves its own permanent role. Some do. Many do not.

## Where one-to-one role migration creates long-term debt

A common mistake in **AEM group model migration** is trying to reproduce the source platform's group count or exception structure in Drupal.

That approach can feel safe because it appears to reduce change. In practice, it often imports the least maintainable parts of the legacy estate.

One-to-one migration creates long-term debt when it leads to:

*   too many narrowly differentiated roles
*   overlapping privileges that are hard to reason about
*   exceptions created for individual teams rather than repeatable governance patterns
*   approval logic scattered across role definitions instead of explicit workflow design
*   administrative burden that grows every time the organization changes

It also makes future audits harder. When the target state mirrors legacy complexity without clear rationale, governance teams inherit a permission model that is difficult to explain, validate, and evolve.

A better approach is to define explicit migration principles, such as:

*   prefer role consolidation where business risk allows
*   avoid user-specific privilege design except for tightly controlled operational cases
*   express repeatable process through workflow before creating permission exceptions
*   reserve elevated administrative capabilities for small, well-defined groups
*   create documented criteria for regional or business-unit variants

This does not mean oversimplifying enterprise needs. It means ensuring complexity is intentional and governed.

In multi-team and multi-region publishing environments, some nuance is unavoidable. The objective is not minimalism for its own sake. The objective is a model that remains understandable after the migration team has left.

## Validation steps before cutover

A permission model is not validated because it looks tidy in a spreadsheet. It is validated when representative users can perform the right work, in the right order, with the right boundaries.

Before cutover, teams should run structured validation across both governance and operational scenarios.

### 1\. Build scenario-based test cases

Do not test only by role name. Test by real publishing behavior.

Examples:

*   a local editor creates and revises a market-specific page
*   a regional approver reviews and rejects content with comments
*   a global brand team updates shared content used across markets
*   an operations team executes an emergency homepage change under controlled conditions
*   a platform administrator supports workflow issues without acquiring unnecessary editorial power

These scenarios expose gaps that raw permission matrices can miss.

### 2\. Validate least privilege and over-entitlement

For each role or access pattern, confirm both sides of the question:

*   Can the user perform the required task?
*   Can the user perform tasks they should not be able to perform?

Migration teams often focus on broken access and overlook excess access introduced by role consolidation or rushed exceptions.

### 3\. Test workflow and permissions together

A role may appear correct until workflow states are exercised. Reviewers may be unable to act on content they can see. Editors may be able to edit content but not advance it. Publishers may bypass intended controls if state transition logic and permissions are not aligned.

Testing should therefore cover full lifecycle flows, not isolated screens or capabilities.

### 4\. Validate regional and cross-team edge cases

In enterprise CMS programs, many failures surface at boundaries:

*   shared content with local overrides
*   region-specific ownership exceptions
*   multilingual review handoffs
*   support escalation during off-hours operations
*   temporary coverage when one team acts for another

These are precisely the cases that legacy AEM permissions may have been quietly handling for years.

### 5\. Document the target governance model

Before launch, produce clear documentation covering:

*   role definitions and intended use
*   approval responsibilities
*   escalation paths and emergency access rules
*   ownership boundaries across teams or regions
*   procedures for requesting access changes after go-live

This is not administrative overhead. It is part of making the target model sustainable.

If the target state is not documented, the organization will start rebuilding undocumented exceptions almost immediately.

## A practical audit output for migration teams

To keep the work actionable, the audit should produce more than observations. A strong output package typically includes:

*   an inventory of relevant AEM users, groups, and inherited permission patterns
*   a summary of workflow participation and approval behaviors
*   identified legacy exceptions and their apparent business rationale
*   a list of control requirements that must survive migration
*   a list of editorial outcomes that can be redesigned in Drupal
*   proposed target roles and governance principles
*   unresolved decisions requiring stakeholder input
*   validation scenarios for UAT and cutover readiness

This gives solution architects, security stakeholders, and CMS owners a shared decision framework rather than a technical dump.

## Conclusion

Permissions are easy to treat as a late implementation detail because they are less visible than templates, content, and frontend features. In reality, they often contain the hidden logic of how an enterprise publishing organization works.

That is why an **AEM permission audit before Drupal migration** deserves its own planning track. It helps teams uncover inherited access patterns, understand where AEM groups and ACLs are encoding undocumented behavior, and make deliberate decisions about what should become a Drupal role, what should become workflow, and what should be retired.

The goal is not perfect parity with the legacy platform. The goal is a target operating model that protects the right boundaries, supports real editorial work, and does not carry unnecessary complexity into the next platform.

When teams do this work early, permission design stops being a quiet source of launch risk and becomes a lever for better governance after migration. That kind of early access and workflow analysis is also a core part of successful [AEM to Drupal migration services](/services/aem-to-drupal-migration), especially when cutover readiness depends on more than content extraction alone.

Tags: Drupal, AEM migration, Permissions, Governance, Enterprise CMS, Workflow

## Explore AEM to Drupal Access and Governance

These articles extend the same migration-readiness lens into adjacent areas that often carry hidden operational risk. Together they show how personalization, workflow automation, dependency mapping, and Drupal-side permission design shape a safer and more governable cutover.

[

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

[

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

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

Sep 14, 2023

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

[

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

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

Jun 18, 2023

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

## Explore Drupal Migration and Governance Services

This article highlights how access logic, roles, and approval paths can become hidden migration risks. These services help translate legacy permissions and editorial controls into a Drupal model that is secure, workable, and ready for implementation. They are a strong next step if you need help auditing the current state, designing target governance, or executing the migration with less operational risk.

[

### AEM to Drupal Migration Services

Content and integration migration with controlled cutover

Learn More

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

### Drupal Governance Architecture

Drupal editorial workflow engineering and permissions model design

Learn More

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

### Customer Data Governance

Stewardship, standards, and CDP data policy and controls

Learn More

](/services/customer-data-governance)[

### Drupal Content Architecture

Drupal content architecture design and editorial operating design

Learn More

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

### Drupal Platform Audit

Enterprise Drupal Technical Assessment & Drupal Health Check

Learn More

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

### Drupal Security & Compliance

Automated Deployments. Reliable Infrastructure.

Learn More

](/services/drupal-security)

## Explore Governance and Migration Case Studies

These case studies show how access control, governance, and platform consolidation were handled in real delivery work. They help contextualize the migration readiness work by showing how editorial rules, workflows, and operational boundaries are translated into maintainable Drupal architectures. Together, they provide practical proof of what it takes to modernize complex content operations without losing control.

\[01\]

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

\[02\]

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

\[03\]

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

\[04\]

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