The First Conversation with Engineers Before a CDP Migration

The migration has a vendor, a budget, a start date, and a marketing team that has mapped every campaign it wants to move. It also has an engineering team that heard about it last week. That team already has a release calendar for the next quarter. It also knows the shop’s purchase event carries the parent product ID, a 2021 decision nobody remembers the reason for.

The migration will ship when engineering says it can, in the shape engineering can build. The first conversation with them decides whether that shape is the one marketing needs. Most projects we’ve joined hold that conversation in month two, after the spec is written. It belongs in week one, before it, and it has seven questions.

Who should be in the room

The engineers who will do the work, not the head of IT. The people who own the shop backend, the app, the data warehouse, and whatever sends events today. One marketing person who can say what the campaigns need in terms of data rather than features. And whoever will write the tracking plan, because the plan is the output of this meeting.

Fig 1 · Seven questions for engineering · Ask them in one meeting before the spec

Question one: what sends events today, and who owns each sender?

The website tag, the app SDK, the shop backend, the ERP export, the loyalty system, the call center tool. For each, a named owner and a release cadence. This is the list of senders the migration replaces or reconnects. The answer usually turns up one sender marketing never knew about, and one everybody assumed existed but doesn’t.

What it changes: the integration list, and the calendar, because each owner has one.

Question two: what identifiers exist, and where do they get assigned?

The customer ID from the shop, the email at signup, the device ID from the app, the loyalty number, the cookie. Which ones are stable, which get reassigned after a migration, which are shared across a household or a store terminal. Engineering knows this; marketing usually assumes the email is the ID.

What it changes: the identity rules, written from how IDs get assigned in practice, not from a template. This is the answer that prevents the duplicate-profile problem before it exists.

Question three: which IDs are in which payloads?

The purchase event carries product_id. Is that the SKU or the parent? The view event carries which one? The catalog feed carries which one? Three different answers is normal and it means recommendations and back-in-stock triggers won’t join until someone picks one.

What it changes: a decision, made in the meeting, on the canonical product ID in the data model, and a line in the spec that every event carries it.

Question four: how fresh can the data be, per source?

This is data latency, and it is decided per source, not per platform.

Real-time from the tag; hourly from the app if it batches; nightly from the ERP; weekly from the loyalty export. Marketing plans a “real-time” campaign on data that arrives at 04:00. Engineering knows the cadence and the cost of changing it.

What it changes: which use cases are possible in month one and which need a pipeline change that goes on the engineering roadmap with a date. A back-in-stock trigger on a nightly feed is a daily email; say so before the campaign is promised.

Question five: what can change in the sources, and how will we know?

Field renames, schema changes, app releases that alter an event. Who tells whom. The most common failure we see after go-live: the migration breaks silently at the next shop release. The cause is how the teams communicate, not the technology.

What it changes: a change-notification rule (a message in a shared channel before any release that touches a tracked field) and a monitoring alert on event volume per source. Both are cheap to set up, and together they turn a silent break into a reported one.

Question six: what does engineering need from marketing to say yes?

A tracking spec they can implement without a meeting per event. Event names, properties, types, when fired, from where, in one document. A single point of contact who answers questions the same day. A QA process where marketing tests what engineering shipped, quickly, and reports back in their language.

What it changes: the format of the spec, agreed here, so it is written the way the people implementing it want to read it.

Question seven: what would make this migration fail, in your experience?

Ask it plainly and wait. Engineers who have been through a migration know: scope that grows after the spec is signed, a marketing requester who changes their mind weekly, an integration nobody owns, a go-live date set before the data was checked. The answers are the risk register, and they come free from the people who will carry the risk.

What the meeting produces

A source inventory with owners and cadences. An identity decision. A canonical product ID. A list of use cases split into “month one” and “after the pipeline change.” A change-notification rule and a monitoring alert. An agreed spec format. A risk list in engineering’s words.

All of it fits on two pages, and it is the tracking plan’s first draft. The migration plan is written from it, not the other way round.

What changes in how the project runs

Engineering stops being a ticket queue the migration submits to and becomes the team that told the migration what was possible. The spec is written in their format. The QA loop is fast because both sides agreed how it works. And the person who wrote the spec tests the first campaign that depends on it. That way there’s no gap between “we tracked it” and “we used it” for a bug to hide in.

The takeaway

Seven questions, week one, with the people who will build it. What sends, which IDs, which ID in which payload, how fresh, what can change, what they need, what has failed before. The answers are the spec. A migration that writes the spec first and asks engineering afterward ships what engineering could build. That’s rarely what marketing needed.

Read next

• Identity resolution: deterministic, probabilistic, and where each breaks. Question two, written into rules.

• Event taxonomy pruning: fewer events, better data. What to leave behind in the migration.

• The roles you need for a CDP program to work. The data-engineering seat after go-live.