Managing digital content gets harder the more people and systems are involved. Patterns that work fine for small teams tend to fall apart once you have hundreds of developers, marketers, and external vendors in the mix. Decisions that seem reasonable early on often turn into long-term constraints that are expensive and difficult to undo.

By 2009, Kellogg’s was running into those limits. Their web platform was built on a bespoke content management system backed by a third-party Oracle database. The system was costly to maintain, inefficient to extend, and tightly coupled to vendors outside of Kellogg’s control. Any meaningful change required coordination with third parties, and ownership of the underlying content was effectively abstracted away from the business.

Meeting Arbory Digital

Around that time, Arbory Digital had been building custom components on Day CQ 5.2.5 and 5.3 (which would later become Adobe Experience Manager), primarily in higher education environments. Kellogg’s brought Arbory Digital leadership in to oversee a migration to Day CQ 5.3 with the goal of simplifying their architecture and regaining control over their content.

That lack of control became immediately obvious during the transition. While Kellogg’s could still query their Oracle database to run the existing CMS, the third-party vendor refused to provide direct access to the data for migration purposes. In practical terms, Kellogg’s owned the content but couldn’t retrieve it in a usable form.

To work around this, the team designed a custom XML schema in Day CQ 5.3 and built a feed that queried the existing Oracle database directly. The feed extracted the required content and ingested it into the CRX repository on the new Day CQ instance. Because Kellogg’s still had read access to the database, this approach avoided vendor cooperation entirely and allowed the team to recover all of the data that would otherwise have been lost.

With the data in place, the team built custom templates for Kellogg’s recipes, products, and promotional content. These templates were structured to automatically populate from the migrated data, dramatically reducing the effort required to create and maintain pages. Content that previously took hours or days to assemble could now be published in minutes, without custom development work each time.

The migration to Day CQ 5.3 was completed on schedule. More importantly, Kellogg’s ended up with a platform they controlled, a data model that could evolve over time, and a workflow that scaled far better for both developers and marketers. Operating costs dropped, iteration speed improved, and the business was no longer dependent on a single vendor to access its own content.

About The Author

Like what you heard? Have questions about what’s right for you? We’d love to talk! Contact Us

Podcast Episodes