Enterprise migration teams often approach AEM to Drupal replatforming through visible application concerns first: templates, components, integrations, authoring models, and content structure. Those are important. But they are not the whole delivery system.
In many AEM estates, critical production behavior is shaped by Dispatcher. Cache allowlists and deny rules, rewrite handling, URL normalization, authentication bypasses, header controls, invalidation flows, and environment-specific exceptions can all influence how the site behaves at the edge. If those behaviors are not discovered early, the migration scope can be understated at the start and destabilized later in architecture, QA, or cutover.
That is why an AEM Dispatcher audit before Drupal migration should be treated as a planning input to delivery architecture, not as a last-mile infrastructure check. The purpose is not to reproduce AEM one-to-one in Drupal. It is to understand what business and operational behaviors are currently being enforced outside the application so the target state can make deliberate decisions about what to preserve, simplify, relocate, or retire.
Why Dispatcher logic is often underestimated in AEM migrations
Dispatcher is easy to underweight in early planning because much of its impact is indirect. Stakeholders can see pages, components, and APIs. They do not always see the routing and cache rules that influence whether a URL resolves, whether a response is cacheable, which users bypass cache, or how quickly content changes appear after activation.
This leads to a common planning gap: the source CMS is treated as the application, while delivery logic embedded in edge and web-tier controls is treated as operational detail. In practice, that operational detail can shape requirements in several ways:
- It can determine how canonical URLs behave across brand, locale, or market structures.
- It can control whether authenticated or semi-authenticated experiences share infrastructure with public delivery.
- It can enforce selective cache bypass for search, personalization, preview, or commerce-adjacent flows.
- It can influence SEO behavior through redirects, headers, path handling, and cache freshness patterns.
- It can create environment-specific exceptions that are never documented in functional requirements.
For migration leads, the key point is simple: if Dispatcher currently compensates for application gaps, editorial edge cases, or historical platform constraints, those compensations may surface as hidden requirements during Drupal design.
What to inventory: cache rules, rewrites, headers, auth exceptions, invalidation paths
A useful audit does not need to become a low-level Apache tutorial. It should stay focused on behavior, ownership, and migration impact. The most valuable inventory areas are the ones that explain how requests and responses are really handled in production.
1. Cache rules
Start by identifying what is cacheable today and under what conditions.
Look for patterns such as:
- path-based cache inclusion or exclusion
- query-parameter handling
- file-type and selector-based cache treatment
- rules that treat HTML differently from JSON, assets, feeds, or search endpoints
- exceptions for logged-in, preview, or segmented users
- TTL assumptions or freshness controls enforced outside the application
The objective is not just to document rules. It is to understand the business intent behind them. A path may be excluded from cache because it is truly personalized, or because a legacy integration once made caching unsafe. Those are very different migration implications.
2. Rewrite and URL handling
Many enterprises have years of accumulated routing logic that lives partly outside AEM itself. Rewrite rules may support vanity URLs, market-specific directory structures, extension handling, internal path masking, trailing-slash normalization, legacy campaign redirects, or domain consolidation.
In migration terms, rewrite behavior matters because Drupal routing, reverse proxies, and CDN layers can each own different parts of URL logic. Without a clear inventory, teams can accidentally split responsibility across too many layers or miss key behaviors until SEO regression testing.
Focus on:
- inbound rewrites and path normalization
- redirect patterns, including temporary and permanent redirects
- locale or region path rules
- domain-based route differences
- handling of legacy AEM URL conventions that should not survive replatforming
- any rule that changes what the origin application actually receives
3. Response headers and delivery controls
Headers often reveal decisions about caching, security, downstream behavior, and client expectations.
Inventory where headers are set, overridden, or removed, especially for:
- cache-control behavior
- vary logic
- content disposition or content type edge cases
- security-related headers
- CORS behavior where APIs or decoupled frontend elements are involved
- bot or crawler handling where applicable
This matters because Drupal may not need to own all of these concerns directly. Some can be better managed at the CDN or edge layer. But that decision should be explicit, not accidental.
4. Authentication and access exceptions
Some of the highest-risk migration surprises sit in partial-authenticated delivery patterns. A site may be mostly public, but a subset of paths, assets, APIs, or user segments may behave differently. Dispatcher rules sometimes reflect these exceptions through cache bypass, allow/deny logic, or path-specific controls.
Examples include:
- authenticated support content within a largely public estate
- gated downloads or region-specific access conditions
- preview or editorial review paths
- search or account-adjacent functions that share the same domain as public content
For Drupal architects, these distinctions shape target-state decisions around session handling, edge caching boundaries, reverse proxy behavior, and domain separation.
5. Invalidation and purge paths
Migration teams often ask whether Drupal can cache pages effectively. The better question is whether the target platform can invalidate content safely and predictably across all the layers involved.
Audit how content changes are invalidated today:
- which events trigger cache flushes or purges
- whether invalidation is broad or surgical
- whether there are manual operational steps during publishing incidents
- how assets are refreshed
- whether multi-region or multi-domain delivery changes propagation behavior
- where stale content risks have historically appeared
This is especially important when moving to a Drupal architecture that may involve multiple cache layers, such as Drupal internal caching, reverse proxy behavior, and CDN caching. Teams planning a migration to Drupal often underestimate how much of launch stability depends on invalidation design rather than on page rendering alone.
How hidden delivery behavior distorts migration estimates
Undiscovered Dispatcher behavior rarely stays isolated as an infrastructure issue. It tends to spread into scope, sequencing, testing, and launch risk.
A migration estimate can become distorted in several ways.
First, route complexity may be understated. A team may plan for content and template migration while assuming URL handling is straightforward. Later, they discover extensive rewrite logic supporting language variants, campaign shortcuts, historical URL retention, or domain-specific exceptions that require architecture and QA effort.
Second, cache assumptions may be wrong. A path believed to be dynamic may actually be safe to cache with the right edge strategy. Conversely, a path assumed to be simple may depend on fine-grained bypass rules that affect infrastructure design, test coverage, and operational procedures.
Third, delivery behavior may be compensating for upstream design choices. For example, some legacy AEM estates use Dispatcher rules to work around inconsistent URL generation, overly broad cache invalidation, or integration endpoints that should have been isolated behind more explicit boundaries. If those workarounds are not recognized, teams may copy them into Drupal unnecessarily.
Fourth, program planning may miss cross-team dependencies. Rewrite ownership might sit with infrastructure teams, while publishing expectations belong to CMS teams and purge tooling belongs to platform operations. Without an audit, those dependencies appear late and slow decision-making.
For technical program managers, this is why the audit is best framed as migration readiness. It reduces the risk of discovering delivery-critical behavior only after target-state architecture is mostly set.
Mapping legacy routing and cache assumptions to Drupal and CDN layers
Once current-state behavior is visible, the next step is not “How do we rebuild Dispatcher in Drupal?” The better question is “Which layer should own each behavior in the future?”
A Drupal target state typically has more than one place where delivery logic can live:
- Drupal application and module layer
- reverse proxy or web tier
- CDN or edge platform
- identity or access layer
- search or API delivery layer where applicable
Good target-state design depends on assigning concerns intentionally.
Keep application concerns in the application
If a rule exists because content, taxonomy, publication state, or editorial workflow needs to drive behavior, Drupal should usually own it. For example, canonical URL generation, structured redirect governance, and content-driven cache tags belong closer to the application model than to ad hoc infrastructure rules.
Move broad delivery concerns to the edge where appropriate
If a rule is primarily about performance, cacheability, or request normalization across many paths, it may be better suited to a CDN or edge layer. That can include standard redirects, protocol enforcement, header policies, or broadly applicable caching controls.
Separate identity-sensitive flows from public delivery assumptions
If authenticated exceptions are extensive, the right answer may not be more edge complexity. It may be clearer domain separation, a different routing pattern, or a distinct delivery path for user-specific interactions. This often simplifies caching strategy and reduces operational ambiguity.
Re-evaluate invalidation instead of inheriting it
AEM-to-Drupal migrations create a valuable opportunity to redesign purge behavior around the target platform's content relationships and cache model. Instead of preserving broad invalidation patterns because they are familiar, teams should ask whether more structured cache tagging, explicit dependency modeling, or CDN integration can produce a more predictable operating model.
Which patterns should be preserved, simplified, or retired
Not every discovered behavior deserves a place in the future state. A practical audit should produce decisions, not just inventory.
A useful framing is to classify each pattern into one of three buckets.
Preserve
Preserve behaviors that clearly support business-critical delivery outcomes and still make architectural sense.
These might include:
- essential redirect patterns that protect SEO continuity
- region-aware routing logic tied to domain strategy
- controlled cache bypass for genuinely user-specific paths
- purge flows that support required publishing responsiveness across distributed delivery layers
Simplify
Simplify behaviors that solve a real problem but are overly fragmented, duplicated across layers, or hard to operate.
Examples can include:
- rewrite rules spread across multiple environments with minor differences
- path-specific cache exceptions that could be replaced with clearer application-level cacheability rules
- header manipulation that belongs in a shared edge policy
- historical URL handling that can be consolidated into governed redirect management
Retire
Retire behaviors that exist mainly because of legacy constraints, temporary workarounds, or ownership ambiguity.
This often includes:
- outdated vanity URL conventions with no measurable business need
- exceptions created for integrations that no longer exist
- redundant redirect chains
- broad cache bypass rules that were introduced defensively and never revisited
This classification step is where the audit becomes strategically useful. It prevents teams from treating the current state as the default blueprint.
Validation and cutover checks for route and cache parity
Even well-designed target states can fail at launch if route and cache validation is too shallow. Migration teams should define parity in terms of user outcomes, not infrastructure similarity.
A strong validation plan typically checks:
- canonical public URLs and redirect outcomes
- locale and market routing behavior
- cacheability of major page types and service endpoints
- authenticated exception handling where relevant
- cache invalidation behavior after publication or asset updates
- header behavior that affects downstream delivery or security expectations
- search and API request paths if they interact with the same edge stack
For multi-region delivery, parity should also consider whether content freshness and route behavior remain consistent across regions during publishing and cutover windows. Not every enterprise needs perfect global simultaneity, but every enterprise should know what its acceptable propagation model is before launch.
Cutover readiness should include operational checks as well:
- who owns route rollback if an edge rule misbehaves
- how purge failures are detected and handled
- what evidence confirms key redirect sets are working
- which paths are intentionally uncached and why
- how support teams identify whether an issue sits in Drupal, edge configuration, or CDN behavior
This is also where Drupal high availability architecture becomes relevant, especially when route parity, cache propagation, and rollback behavior must hold across multiple regions or failure scenarios.
Common recovery mistakes after launch
When delivery issues appear after replatforming, teams often lose time by making reactive changes in the wrong layer. A few recovery mistakes appear repeatedly.
Recreating legacy complexity too quickly
Under launch pressure, teams sometimes rebuild a stack of source-platform behaviors simply because they existed before. This can lock the new platform into inherited complexity without confirming whether that behavior is still needed.
Using broad cache bypass as a safety blanket
Disabling or weakening caching can reduce symptoms temporarily, but it often obscures the real issue. The underlying problem may be incorrect invalidation, route ownership confusion, or missing cache context rather than a general inability to cache safely.
Mixing redirect, rewrite, and application fixes together
When a URL issue appears, teams may modify multiple layers at once. That makes root-cause isolation difficult and increases the chance of side effects. Recovery is faster when ownership boundaries are clear.
Treating isolated exceptions as proof the target model is wrong
A few edge cases do not necessarily mean the Drupal delivery architecture is flawed. They may indicate that a small number of business rules need better modeling, or that some source-state exceptions were never fully understood.
A practical audit output for migration teams
The most useful audit deliverable is not a raw configuration dump. It is a migration decision artifact that multiple teams can use.
A practical output usually includes:
- a behavior inventory grouped by routing, caching, headers, auth exceptions, and invalidation
- the business or operational rationale for each significant rule set where known
- a target-state recommendation for ownership: Drupal, CDN, edge layer, identity layer, or retirement
- identified risks to migration scope, SEO continuity, publishing operations, and cutover
- open questions that require architecture or stakeholder decisions
- validation requirements for QA and launch readiness
It can also help to map each behavior against a simple matrix:
- Current behavior
- Why it exists
- Future owner
- Preserve / simplify / retire
- Risk if omitted
- Validation method
This turns the audit into a working input for architecture, QA planning, and deployment governance.
For organizations managing complex enterprise digital platforms, that is the real value. An AEM Dispatcher review is not just about understanding a legacy web tier. It is about exposing the delivery logic that quietly shapes migration scope.
When teams perform that audit early, Drupal architecture decisions become more deliberate. Route ownership becomes clearer. Cache strategy becomes more defensible. Cutover planning becomes more realistic. And the target state is more likely to preserve the behaviors that matter without carrying forward the ones that do not. Large multi-site programs such as Veolia show how delivery controls, caching strategy, and governance can materially affect rollout safety at scale.
In other words, the audit does not just explain the source platform. It helps define a better destination.
Tags: Drupal, AEM to Drupal migration, AEM Dispatcher audit, Migration readiness, Drupal delivery architecture, Edge infrastructure
