Image of the MCG

Architecting for performance: Integrating Optimizely and Microsoft Dynamics 365 for the MCG

Solutions Architect Tony Duan explains how Luminary integrated Optimizely and Microsoft Dynamics for the Melbourne Cricket Club and solved complex performance and scalability challenges for one of Australia's most iconic sporting venues.

Tony Duan

27 April 2026

7 minute read

When you manage the digital presence of the Melbourne Cricket Ground (MCG), you aren't just managing a website; you are managing a digital cathedral. For the Melbourne Cricket Club (MCC), the stakes for a platform migration are incredibly high. With a membership base that is as passionate as it is large, the transition from Sitecore to Optimizely needed to be more than a lateral move – it had to be an evolution in performance and user experience.

The primary concern in such a migration isn't usually the front end ‘look and feel’. The real anxiety lies in data gravity. How do you decouple years of legacy logic from a platform and reconnect it to a modern DXP like Optimizely without breaking the critical bond between the member and their data?

Our solution centered on a sophisticated, high-performance integration with Microsoft Dynamics 365, underpinned by a strategic middle-layer architecture that bridged the gap between the stadium and the screen.

The strategic value of the middle layer

MCG middle layer diagram

The MCC’s previous Sitecore implementation utilised a middle-layer database, a strategic buffer between the CMS and the core CRM.

We chose to retain and modernise this middle-layer approach. By utilising Entity Framework for data handling, we created a robust abstraction layer. This meant that Optimizely didn't need to ‘talk’ directly to the complex, often slower schemas of a live CRM every time a page loaded. Instead,  member requests pass through authorised API controllers, into purpose-built service layers with layered caching, before ever reaching the optimised middle-layer database, and in most cases, the cache answers before the database is touched at all.

The scope of this middle layer is significant. It manages over 30 entity tables spanning the core data domains of the club: membership profiles and categories, event and dining management, function bookings and packages, ticketing transactions, and room and product catalogues. Each of these domains is served by a dedicated data service within the Optimizely application, purpose-built to expose only what the website needs, with read-optimised defaults to keep page loads fast.

This technical approach allowed for collaborative schema updates. Because we controlled the middle layer, we could work hand-in-hand with the MCC’s internal data team to map Dynamics fields to the website’s requirements in real-time.

Managing the shared schema

The middle-layer database sits between two independent teams, and the schema must serve both. The MCC's internal data team are the primary custodians. As the owners of the CRM and the source of truth for member data, they drive the majority of schema changes and manage the middleware tool to keep Dynamics and the shared database in sync. These pipelines run entirely within the MCC's on-premises infrastructure, so member data never leaves the club's secured network.

Our role at Luminary is to consume that schema from the Optimizely side using Entity Framework Code-First migrations. But we don't operate in isolation. We are actively involved in the design process, influencing schema decisions, reviewing pull requests, and ensuring changes work for the website's data access patterns as well as the CRM's synchronisation needs.

The critical rule underpinning this collaboration is backwards compatibility. Because the database and the application deploy independently, every schema change must be safe to deploy in isolation. New columns are always nullable on introduction, new tables are additive, and destructive changes are avoided outright or handled across multiple coordinated releases.

Solving for scale

The MCG isn't a steady-state business. It operates in bursts of extreme intensity. On the morning of a Grand Final or the Boxing Day Test, the surge in traffic to the member portal is exponential. A direct-to-CRM integration model would likely buckle under the weight of thousands of simultaneous authentication requests and profile lookups.

By leveraging the middle layer as a high-speed cache and synchronisation point, we effectively mitigated latency. When a member logs in, the data they see is served from the optimised middle layer, while background processes ensure that any updates (like a change of address or a renewed membership) are eventually consistent with Microsoft Dynamics 365.

This architecture provides the elasticity required for high-traffic events. It ensures that the game day experience is never marred by a spinning loading icon, protecting the brand reputation of both the MCC and the MCG.

Azure B2C and the Salesforce connection

While the primary focus of this build was the Optimizely-Dynamics integration, the broader ecosystem involved a complex interplay with Azure B2C and Salesforce.

In this architecture, Azure B2C acts as the identity provider for member security. Member data originates in the CRM ecosystem, whether that is Microsoft Dynamics 365, Salesforce, or another source, and is synchronised into the middle-layer database via integration pipelines.

This highlights a critical capability – the ability to manage multi-cloud data flows. Even if your organisation is currently debating between an Optimizely Salesforce integration or a Dynamics-led approach, this ‘Hub and Spoke’ model proves its worth. It centralises the source of truth in the middle layer, making the CMS agnostic to where the data originated, provided the integration is secure and well-architected.

The middle-layer schema doesn't care whether a member record was pushed from Dynamics via a middleware tool or from Salesforce via an API. It only cares that the data conforms to the agreed contract.

UX and the data-driven interface

The ultimate beneficiary of this technical heavy lifting is the MCC member. By integrating Dynamics data so deeply into Optimizely, we were able to create a highly personalised user experience.

Membership at the MCC is tiered, complex, and steeped in tradition. The website needs to know – instantly – what a member's status is, what tickets they are eligible for, and what areas of the stadium they can access. By bringing this data into the Optimizely environment via Entity Framework, we enabled the marketing team to use Optimizely’s personalisation tools with CRM-level precision. 

The mechanics of this personalisation are worth understanding. When a member authenticates via Azure B2C, the application immediately looks up their profile in the middle layer and enriches their session with membership-specific claims: their category, their status, their entitlements. These claims are then evaluated by Optimizely's visitor group engine. We built custom visitor group criteria that can segment members by their membership tier and even by their AFL or BBL team of support. This means the content team can create targeted experiences that go far beyond simple name personalisation.

This isn't just "Hello [First Name]"; this is a dynamic display of membership rights and tailored content driven by real-time data.  A Full Member can see different event options than a Provisional Member. A member who supports the Melbourne Demons might see different hero content on Boxing Day than one who supports the Sydney Sixers. And all of this is powered by the same middle-layer data that the MCC team maintains through their Dynamics integration.

A partnership in data

One of the most significant ‘solves’ in the MCC project wasn't technical; it was cultural. Large-scale integrations often fail because of a silo effect between the agency and the client’s internal IT team. Luminary and the MCC operated as a joint squad. The MCC team owns the Dynamics data; they are the stewards of the club’s most valuable asset. Our role was to provide the ‘pipes’ and the ‘vessel’ (Optimizely) to display that asset.

Why this matters

If you are currently invested in the Microsoft ecosystem and considering a move to Optimizely, the MCC project serves as a blueprint for success. It demonstrates that you don’t have to sacrifice your existing data structures to achieve a modern, agile web presence.

The key takeaways for any organisation embarking on this journey are:

  1. Don't fear the middle layer: It provides the performance buffer and schema flexibility that direct integrations often lack.
  2. Prioritise identity: Use tools like Azure B2C to decouple identity from data, increasing security and scalability.
  3. Collaborate on schema: Your agency should work with your data team, not in a vacuum. Cross-team pull request reviews and shared schema ownership prevent integration failures before they happen.
  4. Design for backwards compatibility: When multiple teams own different sides of the same database, every schema change must be safe to deploy independently. This discipline is what enables independent release cadences across teams.

The result of the MCC Sitecore to Optimizely migration is a platform that is as robust as the concrete of the Great Southern Stand and as agile as the athletes on the turf. By deeply integrating Optimizely and Microsoft Dynamics 365, we’ve ensured that the MCC is ready for the next decade of digital evolution.

Want to tap into the expertise of a multi-award winning Optimizely Solution Partner?

Get in touch

Keep Reading

Want more? Here are some other blog posts you might be interested in.