A cloud or data migration can look finished and still be a liability. The demo runs cleanly, the slides get signed off, the consultants roll off the project, and three months later the platform has not moved an inch since handover. No one in-house can extend it, and the running costs are climbing for reasons nobody can quite explain. The build itself was rarely the problem. What was missing is everything that lets a system outlive the people who built it.
A migration is measured a year later, by what is still running and who is able to run it.
Certification measured the wrong thing
Plenty of organisations track certification counts as a proxy for readiness, and it is a poor one. People memorise the material, pass the exam, and are then handed a real workload they cannot actually deliver. A certificate confirms that someone answered questions correctly on a particular day, which says nothing about whether they can read a messy requirement, choose an architecture under real constraints, or bring a pipeline back at two in the morning. So the workforce accumulates badges and still ends up calling the consultants back.
The pattern on the slide was built for someone else
A reference architecture lifted from a conference slide carries an air of authority and is usually wrong for the problem actually in front of you. The original came with constraints, trade-offs, and a context that no longer apply, and once it is copied without that understanding it tends to impress in the pitch and then fail the security review, overrun the budget, or refuse to scale. Real design is the set of decisions underneath the diagram, why this pattern fits, when it would not, and what is being traded away to use it. Leave those decisions out and a diagram is all you are left with.
Finished has to mean it runs
Too many builds are declared finished at the moment they first work on the builder’s own machine. Delivery that holds up treats idempotency, testing, monitoring, and cost control as part of what “done” even means. A platform you cannot deploy repeatably, watch in operation, or scale without alarm is not so much finished as fragile, and it grows more fragile the moment the people who built it move on.
The handover is the deliverable
The most expensive failure in a migration is usually the one nobody notices on the day. The knowledge walks out with the consultant, very little of it was written down, and the platform quietly freezes in the state it was left in at the end of the contract. Handover is not the closing formality it tends to be treated as. It is closer to the point of the whole engagement, which is why the work should be built for operability from the outset, documented as it goes, and handed to a team that can run and extend it without us.
What this looks like in practice
We have done this inside banks and government bodies, where the data is sensitive, the regulator is paying attention, and a failed system cannot simply be thrown away and rebuilt. The approach does not change much from one to the next. We map the existing landscape before designing the target, settle what a modern platform actually has to do before arguing about the tools that deliver it, build to production discipline throughout, and leave behind a team that no longer needs us. If that is the standard you are after, talk to us.