After the workloads land
The migration finished. The bill went up. Now what.
Cloud transformation work at TechFabric starts after the move, where most of the value is and most programmes stop. Rearchitecting the workloads whose running cost never came down, replacing the operational habits that came across with the servers, and getting release cadence to the point where the platform pays for itself.
A year after a migration the pattern is familiar. The workloads run, the bill is higher than the data centre it replaced, deployments still happen on Thursday nights, and nobody can say which of the three hundred resources are still doing anything. The move was real. The change never happened.
- Who it is for
- CTOs and platform leaders holding a cloud bill that outgrew the business case
- Bench
- 115+ engineers, 80 Databricks-certified
Where we start
- Spend by workload against what each one earns or enables, not spend by resource type
- The resources nobody has claimed, which is usually a larger number than expected
- Release cadence, and what specifically makes a deploy an event rather than a routine
- Which workloads are paying cloud prices for a data centre architecture
- Where durability was assumed rather than built, so a retry means a support ticket
- The three or four changes that would move the bill, ranked by effort
What changes
- Rearchitecture of the workloads where it pays, and nothing done to the ones where it does not
- Managed services replacing the things your team runs but should not
- Deployment made routine, which is the change that makes every later change cheaper
- Durable execution under the long-running operations, so partial failure stops being an incident
- Cost attribution that a business owner can read, rather than a resource-level export
- A written record of what was rejected and why, because that is what a handover normally loses
FAQ
Cloud transformation: common questions
What is cloud transformation?
Changing how software runs now that it is in a cloud, rather than moving it there. Rearchitecture where the running cost justifies it, managed services in place of things your team maintains by hand, and deployment becoming routine. A migration moves the workload. This is the part that was supposed to make it worth doing.
Our cloud bill went up after we migrated. Is that normal?
It is extremely common, and it is usually architecture rather than pricing. Workloads sized for a data centre run continuously in a place that bills continuously, and the savings assumed in the business case needed changes nobody scheduled. The first thing worth doing is attributing spend to workloads, because that turns one large number into a short list.
Do we have to rearchitect everything?
No, and you should not. Most estates have a handful of workloads where the running cost or the change frequency justifies the work and a long tail where it never will. Spending evenly across both is how a transformation programme runs out of money before it reaches the parts that mattered.
How do you measure whether it worked?
Against numbers the business already tracks: monthly run cost per workload, lead time from merge to production, and how often a release needs somebody awake at night. Agreed before the work starts, because a metric invented afterwards is how a programme reports a success nobody felt.