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.
- Who it is for
- CTOs and platform leaders holding a cloud bill that outgrew the business case
- Bench
- 115+ engineers, averaging 15 years each
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 and the change never happened, which is the outcome nobody budgets for and most estates reach.
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
Why the bill went up, and the half of the plan that was skipped
A higher bill after a migration was usually written into the plan. AWS's own large-migration guidance recommends rehosting, relocating or replatforming first and modernising after the move, because refactoring hundreds of applications mid-migration is too much to manage at once.
That's sound advice, and it means the savings in the business case sat in a second phase. When the programme closes after the first, you're left paying cloud prices for an architecture sized to run continuously in a data centre.
The same guide gives a test worth running a year later. A workload averaging under 5% CPU and memory is a zombie, and one between 5% and 20% over 90 days is idle. Both were candidates to retire before the move, and anything that met the test and moved anyway is still billing every hour.
Cost by workload, before anything else
A bill grouped by service type tells you the estate spends a lot on compute. A bill grouped by workload tells you which three systems to look at first, and that grouping depends on tags the billing tools actually read.
On AWS, a tag on a resource does nothing for cost reports until its key is activated as a cost allocation tag in Billing and Cost Management. The key can take up to 24 hours to appear for activation and up to another 24 to activate.
On Azure, the tag inheritance setting in Cost Management applies subscription and resource group tags to the usage records of everything under them, so you don't have to tag every resource. It's available on Enterprise Agreement, Microsoft Customer Agreement and Microsoft Partner Agreement accounts, and it updates the current month only. Turned on 20 October, it relabels usage from 1 October, and September stays as it was.
01
Attribute spend to workloads
Activate the cost allocation tags or turn on tag inheritance, then read spend per workload against what each one earns or enables.
02
Find what nobody claims
Resources with no owner and no tag, and the zombie and idle servers that came across in the migration. This list is usually longer than expected.
03
Rank three or four changes
The few changes that would move the bill, ranked by effort, with the long tail deliberately left alone.
04
Make deploying routine
Find what makes a release an event, whether a manual step, a freeze window or a person who has to be awake, and remove it. Every later change gets cheaper after this one.
05
Build durability where it was assumed
Long-running operations moved onto durable execution, so a step that fails partway resumes instead of turning into a support ticket.
06
Write down what was rejected
Each option considered and turned down, with the reason, because that's the part a handover normally loses.
Numbers to have before you start, agreed with the business
- Monthly run cost per workload, not per service type
- How many resources have no owner tag today
- Lead time from merge to production, for your three busiest systems
- How many releases last quarter needed someone working at night
- Which workloads have averaged under 20% CPU and memory for 90 days
- Which Software Assurance or reserved commitments expire in the next twelve months
Checked on 11 October 2026 against AWS: activating user-defined cost allocation tags and Microsoft Learn: tag inheritance in Cost Management.
Clients we have done this for
B2B ecommerce
AmTab
AmTab, a table manufacturer, had orders moving between departments on paper while demand climbed. Senior engineers from TechFabric worked through those manual steps with AmTab's own people first, then connected the amtab.com store, the CRM and Business Central, so an order placed online reaches the ERP that invoices it without anyone retyping it.
Agentic GTM
Canvass
An application on Cloudflare that researches accounts and prepares outbound campaigns for Canvass's clients, where one bad email costs a prospect. A person approves every send, a run that dies halfway can't message a contact twice, and each email is checked again the moment it goes out.
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.
The rest of cloud
Cloud migration
Infrastructure and platform leaders with a deadline and a partial inventory
Application modernization
Engineering leaders whose release cadence is falling and cannot stop shipping
Azure consulting
Engineering and infrastructure leaders on Microsoft's cloud, or moving onto it
AWS consulting
Engineering leaders running production on AWS, or moving a workload there