Migrated Laithwaites to a new ESP and deployed dynamic email personalisation with zero disruption to live campaigns, then introduced Kanban to cut production turnaround time.
→ Dynamic personalisation deployed across the customer base. Migration completed with no disruption to campaign delivery.
Problem
Laithwaites was running on a legacy ESP that put a hard limit on personalisation, with most customer email effectively one-size-fits-all, and moving to a more capable platform couldn’t disrupt the live campaigns already running through the old system.
Context
This was really three connected pieces of work, the platform migration itself, the dynamic personalisation programme it unlocked, and a process change to production once the new capability was live, rather than a single initiative.
Business objective
Migrate to a new ESP and deploy dynamic email personalisation without disrupting live campaigns, then adapt production process to make use of the new capability.
Customer/user objective
Customers needed email that reflected them individually rather than a single generic send, once the new platform made that possible.
Constraints
The migration had to happen without disrupting the live campaigns already running through the legacy ESP, which meant no clean cutover window to work with.
Stakeholders
The ESP supplier, the technical team building the dynamic content rules, and the wider email production team whose workflow changed once Kanban was introduced.
Research and discovery
I mapped the existing email programme architecture and data structures first, so I understood the real scope of the migration rather than guessing at it.
Options considered
I considered a full platform cutover in one move versus a staged migration that kept the legacy system live in parallel. I chose the staged approach, since a single cutover risked disrupting live campaigns with no fallback if something didn’t transfer cleanly.
Prioritisation
Understanding the existing architecture came before specifying the personalisation programme, since building dynamic content rules against data structures I hadn’t fully mapped risked rework once the real scope became clear.
Delivery
I specified what the personalisation programme needed and worked with the technical team to build dynamic content rules against customer segments, managed the migration timeline and coordinated directly with the supplier, then introduced Kanban to manage ongoing email production once the migration was complete.
Decisions made
Introducing Kanban after the migration, rather than trying to change production process and platform at the same time, was the decision that mattered most, it meant the team adjusted to one change at a time rather than two at once.
Trade-offs
Sequencing the platform migration before the process change meant the team didn’t get the full benefit of the new capability immediately. I judged that worthwhile to avoid overloading the team with simultaneous change.
Business outcome
Dynamic personalisation went live across the customer base, the migration completed without any disruption to live campaigns, and the Kanban process brought turnaround times down across the team afterwards.
Customer outcome
Customers received email genuinely tailored to them rather than the one-size-fits-all sends the legacy platform had limited the team to.
Lessons learned
Sequencing a platform migration and a process change separately, rather than together, gave the team room to properly adopt each before the next landed.
What I'd improve today
I would scope the Kanban process change alongside the migration plan from the start, so the team knew it was coming rather than it emerging as a separate initiative afterwards.
