Most migration case studies make delivery look immaculate. That is useful for showing the finished work and less useful for a technology leader trying to judge how a partner behaves when the plan stops matching reality.
On one Distinction migration, three problems changed the cost, timetable or direction of the work. One came from an audit that was too shallow. One came from a third-party API that failed at realistic volume. One followed a change of client sponsor. Each exposed a gap in our own approach, so this is an account of what happened, how the team responded and what we changed afterwards.
The point is not that problems prove a project is badly run. Migrations combine old content, undocumented decisions, external systems and changing organisations. Surprises are likely. What matters is when they become visible, whether the people responsible explain their part clearly, and whether the client gets real choices rather than a disguised request for more budget.
A content estate that was three times more varied than it looked
The initial audit identified 11 content types in the legacy CMS. We sampled pages, estimated 18 days for migration and included that figure in the plan. Once migration began, the apparent consistency disappeared.
Around 35% of the pages used bespoke component configurations that were absent from the template library. A former developer had created them individually over several years. Embedded media also pointed to files that had since moved or disappeared. Eleven nominal content types concealed closer to 30 practical variations.
Our estimate rose from 18 days to just over 60. That was a re-scope, beyond normal contingency.
The weakness was in our method. We had examined CMS definitions and sampled pages at template level. On a seven-year-old platform touched by several developers, we should have inspected a deeper sample at component level. The defined model told us how the system was supposed to work; it did not reveal enough about how editors and developers had actually used it.
Within 48 hours, we spoke directly with the project sponsor and set out the effect on time and cost. We offered three routes: migrate every variation manually, use Henry, Distinction's migration accelerator, to handle recurring variation programmatically, or rationalise the estate and move a smaller, cleaner set. The client chose the accelerated route. It added five weeks and about £18,000 to the budget.
Those figures and circumstances come from Distinction's project record and should be checked internally before publication. The transferable lesson does not depend on them: an audit of an ageing content estate must test implementation drift, rather than trusting the CMS model alone.
We now include a deeper page sample in content audits, inspecting components and embedded dependencies as well as templates. The percentage should respond to risk: age of platform, number of past contributors, prevalence of custom code and quality of documentation. A fixed sample can create false comfort if the odd pages are precisely the ones it misses.
A third-party API that worked until realistic traffic arrived
The second failure involved a CRM integration. The available documentation did not state a rate limit, and no limit emerged during technical discovery. Functional tests passed because each lookup returned the correct data.
Load testing changed the picture. A simulation of roughly 180 simultaneous portal users triggered throttling after about 2,800 requests in an hour. Profile pages then took 12 to 18 seconds to load, and around one in four requests timed out.
The vendor's undocumented policy contributed to the problem. Our testing also had a clear gap: we had verified correctness without testing sustained, production-like demand against the external service. An integration can be logically correct and operationally unusable.
The team added a caching layer, queued requests that did not need an immediate response and negotiated a higher rate limit. The higher tier cost the client an additional £6,000 a year, which had not appeared in the business case. Distinction absorbed its own time on the fix because a stronger testing protocol should have exposed the constraint before launch. The resolution took three weeks.
Again, the detailed numbers require confirmation against the engagement record before publication. The more important procurement question is broader: what usage limits, throttling rules, retry behaviour and commercial tiers apply when the integration is under sustained load? A vendor answer in writing is more useful than an assumption inferred from a successful development test.
Our integration approach now includes load-to-break testing for important third-party APIs. The goal is to find the practical ceiling, observe how the system degrades and decide which calls can be cached, queued or avoided. We also seek written confirmation of fair-use policies and rate limits before architecture sign-off.
A new sponsor who reopened the architecture decision
Six weeks into the same engagement, the client's Head of Digital left. Her replacement arrived from outside the sector and wanted to revisit the headless architecture. He had experienced a poor headless implementation elsewhere and was concerned about editorial usability.
It would be easy to describe that as a client changing direction. That account would omit our own weakness. The original decision had sound reasoning behind it, although we had not preserved that reasoning well enough. We had recorded the selected architecture without creating a durable account of the alternatives, trade-offs, evidence and assumptions.
The new sponsor therefore inherited a conclusion rather than a decision trail. Six meetings and roughly four weeks of renewed discovery followed. The team ultimately retained the headless direction and changed two aspects of the editing experience. Those changes added about three weeks and £14,000. The delivery team also lost momentum while the decision remained open.
This was useful scrutiny. The new sponsor raised a legitimate usability risk, and the final implementation improved because of it. The avoidable part was having to reconstruct the original case from conversations and memory.
Material decisions now receive a short record: what was decided, which alternatives were considered, why the chosen route won, which assumptions matter and who participated. When a key sponsor changes, a structured realignment session can then start with the evidence and identify what has changed. It is faster and fairer than treating either the old decision or the new concern as self-evidently correct.
What these failures changed
The three root causes were different: inadequate sampling, incomplete resilience testing and weak decision memory. Their common feature was governance. None could be solved by choosing a more fashionable CMS or adding another delivery ceremony.
Good governance does not remove uncertainty. It makes uncertainty visible while there is still room to respond. That means escalation routes agreed in advance, decision records people can inherit, realistic tests of external dependencies and conversations that distinguish a delivery mistake from a newly discovered fact.
There is also a commercial point. When a serious issue appears, a client needs the consequence, the cause, the available choices and a recommendation. Euphemisms such as “challenge” or “learning” make the meeting easier for the supplier and harder for the person accountable for the budget. Owning the gap is part of the work.
The strongest migration team is rarely the one with a story in which nothing ever went wrong. It is the one that can show how problems surface, how responsibility is handled and how the process improves afterwards.
Every agency tells you their projects go smoothly. I want to know what happens when they don't.
Fair. Now you know what happens when ours don't. And if that's the kind of transparency you'd want from a partner on your own migration, let's talk - no deck, no pitch, just a straight conversation about your project.
