How a mid-market music rights organisation delivered a fully operational Dynamics 365 marketing capability and achieved long-term self-sufficiency

Without disrupting royalty distributions, without depending on external vendors post-launch, and without leaving the internal team behind.

Full Dynamics 365 migration across Finance, Customer Service, Sales, and Marketing · Marketing reporting built from zero to real-time daily dashboards · Daily, weekly, and monthly views with user permissions and access control · Internal team capability transferred for long-term self-sufficiency

The bridge. A mid-market music rights and licensing organisation in Australia and New Zealand was mid-way through one of the most significant technology programs in its history: a full migration to Microsoft Dynamics 365, covering every major business function. The marketing module needed specialist leadership that the existing delivery teams could not provide. Today, the module is live, integrated, and operated by an internal team that was built to maintain and extend it without outside support. That shift is the work.

The client is a leading music rights licensing and distribution organisation in Australia and New Zealand, representing tens of thousands of music creators and distributing hundreds of millions of dollars in royalties each year. The organisation’s technology infrastructure is not just an operational concern: it underpins the accuracy and timeliness of royalty flows that creators depend on. When the organisation embarked on a full migration to Microsoft Dynamics 365, covering Finance, Customer Service, Sales, and Marketing, the stakes were high and the scope was substantial.

EY was engaged to lead the broader program, bringing structure and delivery capacity to a migration of this complexity. For most modules, the delivery teams were in place. The marketing module was the exception. The organisation needed someone who could sit alongside EY and the internal teams, bring specialist technical and analytical expertise, and take ownership of the marketing module from scoping through go-live and beyond.

SeidrLab was contracted to fill that role. We were not a peripheral support function: we were the technical SME for the marketing module, responsible for data management, process design, analytics implementation, and the integration points between marketing and the broader Dynamics 365 environment. The brief was to deliver a module that worked, that connected cleanly to the rest of the program, and that the internal team could own once the engagement concluded.

How we led the marketing module from scoping to go-live

The marketing module of a Dynamics 365 implementation is not a standalone product. It sits at the intersection of the sales system, the finance system, and the customer data environment, and it has to work correctly in all three directions simultaneously. Scoping the module required understanding not just what marketing needed but what constraints and dependencies existed across the broader program.

We worked alongside EY and the client’s internal teams to define the scope in detail, map the data flows, and design the processes that would govern how the marketing function operated within Dynamics 365. This was more than a technical specification exercise. It involved interviewing stakeholders across the marketing team, understanding the workflows they were currently running, and designing a system that improved on those workflows rather than simply digitising them.

The implementation itself required close coordination with the other module leads across the EY program. Changes in the sales or finance modules had downstream consequences for marketing, and vice versa. We managed those dependencies carefully, attending cross-module reviews, flagging potential conflicts early, and ensuring that the marketing module’s integration points were tested against real data before go-live.

Key takeaway. In a multi-module enterprise migration, the integration points between modules are where implementations most commonly break. Treating those interfaces as first-class design concerns from the start prevents the late-stage surprises that derail go-live timelines.

How we built data infrastructure that survived launch

Going live is not the end of an enterprise technology implementation: it is the beginning of the harder work. The system that exists on go-live day is inevitably different from the system the business needs six months later, and the infrastructure underneath it needs to be robust enough to support that evolution.

Post-launch, we took on responsibility for the database infrastructure underpinning the marketing module. We built ELT pipelines that moved data cleanly between Dynamics 365 and the reporting environment, handling the volume and variety of data that a large rights management organisation generates. The pipeline architecture was designed for reliability and maintainability: it would not require specialist intervention to keep running, and when something needed to change, the change could be made safely without touching downstream systems unexpectedly.

The pipelines also fed the automated reporting system we built for marketing and financial performance. Before these systems were in place, performance reporting in the marketing function required manual data extraction and assembly. After, reports ran on a schedule and produced consistent outputs that teams could rely on without spending time preparing them.

Key takeaway. Post-launch data infrastructure is often scoped as an afterthought in enterprise implementations, which creates a gap between what the system can do on day one and what the business needs to operate it day to day. Building that infrastructure as part of the engagement, not as a follow-on project, closes that gap before it becomes a problem.

How we built reporting from zero to real-time daily dashboards

Before SeidrLab’s involvement, the marketing function had no reporting infrastructure. The business data team held a six-month backlog of finance and sales reports, but the marketing and sales teams could not wait that long to understand what their staff and customers were doing, and whether the processes were working. Visibility into marketing and sales performance was effectively absent.

SeidrLab was brought in as a dedicated data resource embedded within the marketing and sales team. The brief was not to queue behind the backlog: it was to build the reporting capability marketing and sales needed, directly and quickly.

We designed and deployed automated dashboards that gave both teams real-time visibility into performance from the moment they went live. The reporting was broken down by team, by metric, and by financial line. Views were built at three time horizons: daily for operational monitoring, weekly for trend analysis, and monthly for strategic review. User permissions and access controls were configured so that each team saw the data relevant to their function without navigating a consolidated report.

By the end of the engagement, the marketing and sales functions had a reporting environment that updated daily without manual intervention. Staff could open a dashboard and see current performance rather than waiting for a report to be assembled. That shift, from no visibility to real-time instrumented dashboards, happened within an engagement that also delivered the Dynamics 365 marketing module itself.

Key takeaway. In a function that has had no reporting, the priority is getting to reliable visibility quickly, not building the perfect analytics framework. A good dashboard available today is worth more than a comprehensive one available in six months.

How we built internal capability for long-term self-sufficiency

From the beginning of the engagement, we treated knowledge transfer as a core deliverable rather than an optional extra. The goal was not to build a system that the organisation would need to return to us to maintain. It was to build a system and, alongside it, the internal capability to operate and extend it independently.

This shaped decisions throughout the engagement. We documented everything, not in the minimal way that satisfies a contractual checkbox but in a way that a team member encountering the system for the first time could follow. We ran working sessions with the client’s internal reporting and analytics teams that were designed to build understanding, not just demonstrate capability. When we made technical choices, we explained them in terms that non-specialist team members could reason about.

By the end of the engagement, the client’s internal team was running the marketing module, maintaining the data infrastructure, and operating the reporting environment without external support. That was the measure of success we had set at the outset, and it was the measure we met. The implementation was subsequently recognised by the platform vendor as a strong example of the Dynamics 365 program.

Key takeaway. Knowledge transfer that works requires designing for it from day one, not bolting it on at the end. The system you build should be legible to the people who will operate it, which means making deliberate simplicity choices throughout delivery.

What changed

Before. A complex, multi-module enterprise technology program was underway with no specialist resource to lead the marketing module. Marketing data was siloed from the broader system, performance reporting required manual effort, and there was no clear path to the internal team owning the technical infrastructure post-launch.

After. The marketing module is live and integrated with Finance, Customer Service, and Sales within Dynamics 365. ELT pipelines run automatically, feeding a reporting environment that gives the marketing and finance teams consistent, reliable performance data without manual assembly. The internal team operates and maintains the system independently, with the capability to extend it as business needs evolve.

---

---

Does this fit your situation?

If you are running a complex enterprise technology program and need specialist technical leadership for a specific module or workstream, or if you have recently gone live on a new system and the post-launch data infrastructure has not been built to support day-to-day operations, we can help.

Book a discovery call →