EngineeringaMulti-Brand,Multi-MarketEnterpriseCMSforHertz

Context

Hertz operates four distinct car rental brands: Hertz, Dollar, Firefly, and Thrifty across 21 markets in 16 languages. Managing content and booking infrastructure at this scale requires a platform that can support brand separation, market-specific configuration, and operational continuity simultaneously.

A standard CMS architecture cannot serve this environment. Brand separation without full platform duplication, currency handling across markets, access control across distributed teams, and booking engine performance under international load all require architectural decisions that are made at the system design stage rather than solved through configuration after deployment.

What Changed

Operating four brands across 21 markets created a content and booking management environment that a conventional single-tenant CMS could not support. Market teams required independent control over their environments without access to other markets or brands. Currency and language handling needed to operate natively rather than through workarounds. The booking engine needed to serve international traffic reliably across all markets from a single platform.

The operational complexity had outgrown the infrastructure supporting it.

Envigo’s Responsibility

Envigo was responsible for designing and building an enterprise-grade CMS capable of supporting multi-brand, multi-market operations at scale. This included the multi-tenancy architecture, multi-currency and multi-language implementation, role-based access control framework, CDN implementation, and the multi-product booking engine. Envigo owned all platform architecture and development decisions.

Strategic Decisions

Decision 1: Architect for multi-tenancy rather than deploying separate instances per brand

The alternative, deploying separate CMS instances for each brand or market would have produced an infrastructure that was simpler to build initially but increasingly expensive to maintain, update, and govern at scale. Envigo chose a multi-tenant architecture that allowed each brand and market to operate with full independence within a single platform. This decision reduced long-term operational overhead significantly and ensured that platform updates, security patches, and feature additions could be deployed consistently across all tenants rather than replicated across separate instances.

Decision 2: Implement CDN architecture to support international performance requirements

Serving 21 markets from a single platform introduced latency risks that a single-origin deployment would not adequately address. Envigo chose to implement CDN architecture to distribute content delivery geographically, ensuring that performance was consistent for users across markets rather than degrading for markets furthest from the origin. The alternative was a single-origin deployment optimised for a primary market and was rejected because performance degradation in secondary markets would directly affect booking conversion.

Decision 3: Build role-based access control as a core architectural component rather than a permissions layer

Access control at this scale (multiple brands, multiple markets, multiple team types) requires a system in which permissions are defined at the architecture level rather than managed through a configuration layer applied after the fact. Envigo built role-based access control as a core component of the platform so that market teams could operate independently without visibility into other markets or brands, and without requiring administrative intervention to manage access boundaries. A permissions overlay approach was rejected because it creates governance complexity that compounds as the number of markets and users grows.

System Design

The platform was designed to support operational independence across brands and markets without architectural duplication. Multi-tenancy created separation at the data and configuration level. Role-based access control enforced operational boundaries without centralised gatekeeping. CDN implementation ensured performance was not a function of geography. The booking engine was built to operate across all product types within a single architecture rather than requiring separate systems per brand.

The result was a platform whose complexity was contained at the architecture level, allowing market teams to operate simply within an environment that was structurally capable of handling the full scope of Hertz’s multi-brand, multi-market operations.

Outcomes

The platform was delivered in three months and deployed across 21 markets in 16 languages, supporting four distinct brands within a single multi-tenant architecture.

Scope Expansion

The engagement has continued since 2010. Platform longevity of this duration reflects both the architectural durability of the initial build and the ongoing evolution of the system to accommodate changes in Hertz’s market footprint, brand portfolio, and operational requirements.

Closing Reflection

Enterprise platform architecture for multi-brand, multi-market operations is primarily a governance problem before it is a technology problem. The decisions that determine whether a platform remains manageable at scale are made before a line of code is written.