Delivering and Managing Marketing Technology Platform Implementations

Prioritise Use Cases Over Features 

I’ve been managing martech migrations for 20 years, both on the client and agency side. In that time, I’ve seen many companies start by thinking about what they need to migrate rather than what they’re trying to achieve.  

The issue with this approach is that you’re always working from the bias of your current setup, rather than setting yourself up to achieve your key use cases and get the most out of your new platform.  

This will often lead to scope creep, along with slipping timelines and rising costs on your implementation. It’s always best to identify your key use cases and work backwards from there. 

Define Your Key Marketing Use Cases Before You Start

These become the anchor for every decision that follows; the data you ingest, the way you phase, the tests you run. Without them you drift back to migrating what you already have rather than building what the business actually needs.

Define the Metric

How will you measure the success of the specific use cases? If you can’t measure it, don’t build it yet.

Reverse Engineer the Data

Once each use case is defined, work backward.

• What exact data fields do you need to execute it?  
• Where will you source them from?  
• How timely does the data need to be in your martech platform?  

Only ingest the data required for your use cases — don’t dump every database you own into the platform “just in case.” Data bloat creates complexity for marketing teams, hinders system performance, and creates compliance complications.

Focus on Data Early

The success of any marketing automation platform hinges on the quality of your data, and how you structure and integrate it.

You need a data model that’s designed to fulfil your key use cases and is as simple to use and maintain as possible.

If your data is siloed, messy, or duplicated, a new marketing technology platform will not magically fix it. It will just distribute your bad data faster.

Audit Your Data

Allocate time purely for data discovery, so you understand what you’re up against before you design anything. Then you can plan and budget for it.

Decide Early How You’ll Stitch Profiles Together

What happens when a user has three different emails? Which system is the ultimate “source of truth” for customer intelligence? Document these deterministic and probabilistic matching rules explicitly.

Keep Your Data Model as Simple as Possible

Complexity adds support overhead, decreases system adoption, and increases the time needed to build and deploy new journeys or campaigns. Pressure-test your intended data model against your key use cases. Don’t just think “happy path”, push it to cover how those use cases are likely to extend over time, long after the initial implementation is finished.

Match Data Timeliness to the Use Case, Not the Technology

Real-time is great but often it adds engineering complexity, cost, and points of failure. Go back to the metric you defined for each use case and ask how fast the data genuinely needs to move to support it: an in-session Next Best Experience or Next- Best -Action model needs near real-time behavioural data; a quarterly newsletter segment doesn’t.

Map this against what your source systems can actually deliver (e.g. batch export, API, webhook, etc.) before committing to an integration pattern. Be honest about where the source system, not your martech platform, will be the constraint.

If you are going to take on additional complexity, then the commercial value of the use cases it supports needs to be worth it.

Build In a Data Migration Buffer

Add time contingency to your data integration phase. You will find issues: dates formatted five different ways, null values where there shouldn’t be, multiple ways of coding key values.

Plan for the unexpected. Platforms often treat dates and nulls in completely different ways, so understand this upfront and plan accordingly.

Deliver in Phases

Avoid a “big bang” deployment as it rarely works. If you try to integrate 15 sources and activate 7 channels simultaneously or in close succession, you’ll still be testing and fixing a year later.

The best martech migrations I’ve managed have all gone live in phases.

MVP

Aim to go live with a minimum viable product within the first few months:

• 1–2 data sources (e.g., CRM and website behaviour).
• 1–2 activation channels (e.g., email and paid social).
• 1–2 core use cases.

If you can measure the first use case and demonstrate ROI or improvement versus your legacy platform, confidence grows across the business. This buys you the goodwill and time needed to tackle the more complex, time consuming scope.

Phased Rollouts

How you phase from here on is an individual choice, and you may have less freedom than you’d like given a looming contract end date on your incumbent platform. If you have time, I’d advocate:

• Crawl: basic data ingestion, identity resolution, and simple audience segmentation
• Walk: triggered journeys and multi-channel orchestration
• Run: predictive analytics, machine learning propensity models, and Next Best Experience.

Under time pressure, the right approach is often to prioritise the most business-critical activity first (once core foundations are in place) to mitigate commercial or regulatory risk. Your phases may end up defined by a combination of journeys and channels which, working backwards, dictate the data and integration requirements.

Dictate the Test Strategy Up Front and Plan for It

Success isn’t just a technical go-live. It’s the activation and enablement of specific business capabilities.

If you don’t define your desired outcomes and success factors upfront, your testing phase will probably overrun.

And if your testing team doesn’t know the exact business destination, they’re only testing whether the buttons work, not whether the solution works.

Your definition of success also shapes your migration strategy. This is most obvious in the classic decision of whether to parallel run, keeping the old system live while you implement the new one.

As with phasing, there’s no universally right answer, only trade-offs worth thinking through carefully.

Why You Should Parallel Run

• It’s a safety net. If your new instance hits a snag at the end of week one, you have an immediate fallback.
• It allows you to validate real-world data outputs side by side to ensure accuracy of data, audiences, etc.

Why You Might Not Want To

• It dramatically increases the workload. Your team is suddenly forced to dual-enter campaigns, and your engineering team has to build temporary integrations to keep data in sync across two different architectures.
• Don’t underestimate the effort required to unpick and explain differences. It’s often a full-time job for one or more people, depending on how much is running in parallel at any one time.

Why You Might Not Be Able To

• If you’ve fundamentally changed your data architecture or your use cases. This becomes a big challenge, as you can’t compare like for like.

Realistic Planning

If your project plan assumes a “happy path” sequence of events and timeline, it will look lovely on paper and the sponsor will sign it off. However, you should be prepared to be disappointed.

The list of things that can go wrong is long. Even with the best planning in the world, something will crop up.

Build contingency into both your timelines and your resourcing. This gives you the time and space to deal with unexpected issues, which will likely deliver better, more durable solutions rather than rushed, temporary fixes that nobody ever revisits and that risk compromising the effectiveness of the system and the outcomes it can generate in future.

Plan for Scope Creep

It’s very unlikely that any business will stand still for the time it takes to implement your new platform.

My recommendation is to plan for anything new you already know is happening alongside your migration, and only freeze data sets and campaigns or journeys at the point you plan to start migrating them.

If you’re not migrating a campaign until month three of your plan, let the business make changes up until that point.

Just make sure the project team has visibility of these changes and a voice at the table to raise any potential impact on the migration project (for example, if a change introduces a new data set and therefore requires more resources).

Governance Should Be a Guardrail, Not a Roadblock

Everything covered so far highlights why project and delivery governance should never be treated as just a reporting exercise.

You need key business and technology decision-makers actively participating and engaged, so that when an unexpected legacy issue is found or a critical new business requirement appears, the right people are in the room to immediately make the hard trade-offs between scope, time, and budget.

A good governance framework:

• Provides clear boundaries.
• Defines what “done” looks like.
• Ensures alignment across tech and business.
• Facilitates key decisions in a timely fashion.

Once those guardrails are set, teams should be empowered to execute.

Governance’s job is to clear roadblocks, not create them. How you do this may be specific to your organisation, but if you feel your process consists of endless checkbox exercises, redundant status meetings, and rigid processes that slow down delivery, it’s broken.

In this case, redesign your framework and don’t start your project until these issues are addressed.

The Team Make or Break the Project

Every use case, data model, and phasing plan you build is meaningless without the people who deliver it. You can have the cleanest strategy in the world, but it’ll have limited impact if the team executing it isn’t engaged and empowered.

Bring Them on the Journey

Don’t treat delivery as something that happens to the team. Involve them in the why, not just the what.

This starts early, when you’re defining success metrics. People who understand the destination from the get-go make better decisions when things don’t go to plan. And they will not go to plan.

Celebrate Success

It’s easy to only ever talk about what’s broken or behind schedule. Mark the milestones — the first live journey, the first use case hitting its metric — and make sure the team hears it, not just the steering committee.

Recognition sustains energy and morale through an implementation project. A team that feels its wins are seen stays engaged and dedicated through the challenging periods.

Empower Them to Make Decisions Within the Guardrails

This is what the governance framework is for and how you generate trust.

If every small decision has to be escalated, you slow delivery down and signal to the team that they aren’t trusted.

Set clear boundaries, then let people operate inside them without having to ask permission for everything. We covered how this might look in our guide to the human side of marketing effectiveness.

One Team, Not Client and Agency

I’ve worked on both sides of the fence, so I can confidently say that the worst thing you can do is create a “them and us” environment. Energy goes into managing the relationship instead of managing the project. Build one team, with one goal, regardless of who everyone works for.

The most successful projects I’ve managed are the ones where nobody outside the team could tell who was client and who was agency. Shared standups, same channels, same accountability for outcomes, not “their workstream” and “our workstream.” Get this right, and the agency’s expertise stops being a resource you’re managing and becomes part of your own team’s capability.

Final Thoughts on Martech Implementation

None of this is complicated in principle, but it takes calm rational heads to hold to it under delivery pressure. Get the use cases right, and the data follows. Get the data right, and phased delivery becomes achievable. Phase the delivery well, test against real business outcomes, govern with judgement rather than process for its own sake, and build one team that genuinely wants to deliver it and you give your platform the best possible chance of delivering what it was bought to do.