Cloud migrations fail for organisational reasons, not technical ones
The storage move is the easy part. What actually derails a migration is ownership, training and the spreadsheet nobody wanted to maintain.
Rosa Macias · Founder & Principal Engineer
We have run a lot of cloud migrations. Not one of them failed because the data would not copy. They fail because nobody agreed who owned the thing after it moved.
The three failure modes
1. No named owner. Shared drives become shared cloud folders with the same permission chaos, now harder to see. Decide ownership before you migrate, not after.
2. Training was a PDF. If people were not shown the new workflow on their own files, they will recreate the old one. We now run a 45-minute session per team, in the tool, with their real documents.
3. The migration became the project. A migration is a means. If it has no success measure beyond "we're in the cloud", the business case quietly disappears.
How we sequence it
- Inventory and tag everything, including the 400GB of duplicate photos in a folder called "old".
- Pick a small, motivated team as the first wave. Their complaints are your free QA.
- Migrate in parallel, keep the old system read-only for 30 days, then archive.
- Measure something a finance lead cares about: licence spend, hours lost to file access, number of support tickets.
The bill does not fix itself
Cloud cost is a design outcome. Without right-sizing, lifecycle rules and a monthly review, the bill grows 3–8% a month without anyone doing anything wrong.
We set a target: every environment we migrate should reduce total monthly spend within two quarters. In our last 20 migrations the average was 27%.
Moving to the cloud is easy. Staying deliberate about it is the job.
Hand over the keys
Document the architecture, train at least two internal people, and make sure every service has an owner with a login they control. A migration where the client cannot operate without the consultant is not finished.