Cloud
Cloud migration and the work that comes after it.
TechFabric moves applications, data and operations onto Azure, AWS, Google Cloud and Cloudflare, and then builds what the move was for. Migration with a cutover you can reverse, the estate mapped before anything is committed, and the platform work that turns a lift-and-shift into something cheaper to run than what it replaced.
The clouds we build on
Microsoft Azure
Where most of our enterprise work lands, usually because the identity estate is already there. App Service and Container Apps for the workloads that do not warrant Kubernetes, Entra ID and Key Vault so nothing ships with a connection string in it, and landing zones adopted where they already exist.
Amazon Web Services
ECS and Lambda chosen against the shape of the traffic rather than the shape of the diagram, RDS and Aurora with the failover actually exercised, and IAM designed around the roles people hold so an access review is possible.
Google Cloud
Cloud Run and GKE for the services, BigQuery where the analytics estate already sits, and workload identity rather than long-lived keys. Usually one part of an estate rather than all of it, which is the normal shape of a real migration.
Cloudflare
The edge in front of the rest, which is where most perceived performance is decided. Workers for the request-time logic that should never reach an origin, R2 where egress would otherwise dominate the bill, and WAF, Turnstile and rate limiting on anything that accepts input.
Three pieces of the same problem
A migration that finishes on time and changes nothing about how the software runs has moved your problems to a more expensive address. The interesting question is never whether the workload starts in the new place. It is what you do in the eighteen months after.
Cloud migration
Migrations rarely fail on the technical work. They fail because the inventory was a spreadsheet somebody built in a week, the exclusions were never agreed, and every wave turns up three services nobody remembered owning. The date moves twice and the business stops believing the plan.
Talk about the migrationCloud transformation
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.
Talk about what comes nextApplication modernization
The rewrite that runs alongside the old system, catches up in eighteen months and switches over cleanly has been attempted many times. What usually happens is that the business keeps needing changes, both systems get them, and the new one never quite arrives.
Talk about the modernizationAzure consulting
Most Azure estates were not designed. They accumulated: a subscription per project, a Data Factory somebody built in a week, a Dynamics tenant integrated by whoever was available. The work is to make what is there governable and cheaper to run, and to build the next thing on it without repeating the pattern.
Talk about AzureAWS consulting
AWS gives you every primitive and no opinion about how they fit together. Most of the estates we are called into are not short of services. They are short of a design that says which of them holds the state, what happens when a step fails at three in the morning, and who can explain afterwards what the system did.
Talk about AWSThe migration landed. Nothing else changed.
A move that finishes on time and leaves the software running exactly as it did has relocated the problem to a more expensive address. Three symptoms say that is what happened.
The bill went up and nothing got faster
The servers became instances of roughly the same size, running roughly all the time, and now they are metered. Nobody sized anything against real load, because the project was measured on finishing rather than on what it cost afterwards.
Releases are exactly as slow as before
The estate moved and the way it is built and shipped did not. Same manual steps, same release window on a Thursday evening, same person who has to be awake for it. The cloud was supposed to fix that, and moving alone never does.
There are two of everything
Half the estate moved, the rest is waiting on a dependency nobody scoped, and both halves are running. Two identity stores, two monitoring stacks, two bills, and a network path between them that somebody rebuilds every few months.
One cause under all three. The project moved machines, when the thing worth moving is how the software is built, released and paid for.
The shift
Three ways an estate moves
Same destination. What differs is what you are holding when the first thing turns out to be harder than the plan said.
Lift and shift, decide later
Quick to finish, and you bought the same estate at a higher price
Rewrite it properly first
Correct in principle, and it does not land
Waves, with the shape changed as you go
Unglamorous, reversible, and finished
What the work actually is
Six things, in the order they usually matter. Most estates need all six eventually and almost none need them at once, so the first job is deciding which wave carries which.
An inventory somebody can argue with
What runs, what talks to it, who owns it and what breaks if it stops. This is where a date becomes defensible or gets quietly moved, and it is the step most often skipped because it produces no visible progress.
Identity before anything else
Entra ID, managed identities and a secret store, decided once. An estate that lands with connection strings in configuration files has inherited its old security posture along with its old architecture.
A landing zone you did not invent
Where the cloud provider has a reference architecture, we adopt it rather than building a parallel one nobody outside the team understands. Novelty in a landing zone is a cost paid by whoever operates it later.
Cutover that can go backwards
Each wave runs both ways until somebody has reconciled numbers from the new path against the old one. A migration nobody can reverse is not a plan, it is a weekend with a lot riding on it.
The data path treated as its own project
Applications move more easily than the data behind them, and the integrations between systems are where the schedule actually goes. Naming them early is what stops month four being a surprise.
Cost and observability from the first wave
Tagging, budgets and alerts set up before the estate is large enough to hide anything, and metrics that show what a request costs as well as how long it took. Retrofitting either one across a finished migration is a second project.
Estates we have moved and rebuilt
B2B ecommerce
AmTab
AmTab grew fast enough to outrun the systems underneath it, and modernised the estate to match the demand rather than throttle it.
Automotive / Fintech
Auto Approve
Auto Approve connects consumers to a nationwide lender network to refinance vehicle loans. TechFabric built an automated approval engine that doubled monthly loans processed and replaced more than four manual workflows.
Supply chain
SmartCert
Certificate and quality-document exchange between manufacturers, distributors, and their customers, replacing email attachments with a traceable system.
If the thing moving is a warehouse
Warehouse and ETL migration has its own pages
Moving a data warehouse is a different discipline from moving an application estate, with its own inventory, its own conversion problem and its own way of going wrong. It starts with a two-week readiness sprint that produces a scope you can put in front of a steering committee.
Migration Readiness Sprint
Two weeks, fixed fee, and a scope with the exclusions written down
Snowflake to Databricks
Teams leaving Snowflake whose scope is still a table count
Synapse to Databricks
Teams leaving Azure Synapse whose dedicated pool, Spark and ADF still live as three projects
Teradata to Databricks
Teams leaving Teradata whose load jobs and macros are still the system of record
FAQ
Cloud migration: common questions
What is the difference between cloud migration and cloud transformation?
Migration moves a workload. Transformation changes how it runs once it is there. Most estates need both, in that order, and the mistake is either doing the first and calling it done, or trying to do both to everything at once.
We usually move the estate as it is, then rebuild the handful of things where the running cost or the release cadence justifies it.
Which cloud do you work on?
Azure, AWS, Google Cloud and Cloudflare. We have no incentive to prefer one, because we resell none of them. Where an estate is already committed to a provider, the interesting decisions are almost never about which cloud and almost always about what shape the workloads take once they arrive.
Can you move our data warehouse too?
Yes, and that work has its own pages because it is a different discipline. Warehouse and ETL migration onto Databricks starts at /databricks/migration-readiness, with the source-specific detail at /databricks/from-snowflake, /databricks/from-synapse and /databricks/from-teradata.
How do you avoid the migration that never finishes?
By writing down what is not coming before anything moves. Most stalled migrations are ones where the inventory was never agreed, so every wave discovers new scope and the date moves again. The assessment exists to produce a list of exclusions somebody is willing to sign.