Global InsurTech Platform

AEM CRX (Content Repository Extreme) is the underlying JCR (Java Content Repository) storing all AEM content — pages, assets, component configurations. When digital asset binaries are stored directly in CRX, the repository size grows proportionally to asset volume. For an InsurTech platform generating large volumes of policy documents, claim images, and marketing assets, this creates repository bloat: increasingly slow backups, degraded query performance as Oak traverses a larger node tree, and complex disaster recovery timelines. Moving binaries to an external datastore like Amazon S3 reduces the JCR to metadata-only storage — the repository stays lean, queries run faster, and asset binaries are served from S3-backed infrastructure rather than the AEM server.

AEM supports pluggable datastore implementations for binary storage. An S3 datastore connector redirects binary writes from the local filesystem (the default FileDataStore) to an S3 bucket. When AEM receives an asset upload, instead of writing the binary to CRX, it writes to S3 and stores only the S3 reference in the JCR. On retrieval, AEM fetches binaries from S3 rather than local disk. A customised connector goes further — adding access control logic, custom encryption configuration, S3 lifecycle policies for asset retention, and handling of InsurTech-specific asset types that standard connector configurations do not accommodate. The result is a decoupled binary storage architecture that scales with asset volume without affecting JCR size or query performance.

Sightly (HTML Template Language, or HTL) is the modern server-side templating language for AEM component development, replacing JSP. JSP custom tags allowed arbitrary Java logic in templates — a security liability, since business logic placed in the presentation layer creates XSS vulnerabilities and tightly coupled code that is difficult to maintain. HTL enforces strict template/logic separation: all logic moves to Sling Models, and templates contain only presentation markup. HTL provides XSS protection by default — a specific concern for an InsurTech platform handling sensitive policyholder data. Migrating to HTL is also a hard prerequisite for AEM as a Cloud Service, making the refactoring a future-proofing investment beyond immediate code quality improvement.

AEM 6.5 introduced significant platform changes: Oak repository updates affecting query performance and indexing, Granite UI component API changes, Dispatcher configuration updates, and stricter deprecation enforcement of legacy APIs still usable in 6.3. In an enterprise codebase with custom components, OSGi bundles, and bespoke integrations, these changes surface as backward-compatibility compilation errors that must be individually diagnosed and resolved — each requiring an understanding of both what the deprecated API was doing and what the 6.5-compatible replacement achieves, with the risk that a quick compilation fix introduces a functional regression. Resolving these errors systematically across a production InsurTech platform, while simultaneously running the S3 decoupling and HTL refactoring workstreams under Jenkins CI, required disciplined branch strategy and change management throughout.