# Cloud migration and the work that comes after it.

> Maybe the data centre contract runs out next year, or the last migration landed and the bill went up while nothing got faster. Either way, our engineers move applications, databases and operations onto Azure, AWS, Google Cloud and Cloudflare, and they do it from inside your team instead of handing the job to people you've never met. We map the estate before anything is committed, move it in waves with a cutover you can reverse, and change how the software is built and released as it goes, so it ends up cheaper to run than what it replaced.

Canonical: https://www.techfabric.com/cloud

---

A migration that finishes on time and changes nothing about how the software runs has moved your problems to a more expensive address. What counts is what you do in the eighteen months after the workload starts in the new place.

## Pages

- [Cloud migration](https://www.techfabric.com/cloud/migration): We migrate applications, databases and operations onto Azure, AWS, Google Cloud and Cloudflare in waves, against an inventory agreed before the first move. Exclusions are written down and signed, each wave is reversible, and the workloads that should be rebuilt rather than moved are identified before anyone commits a date.
- [Cloud transformation](https://www.techfabric.com/cloud/transformation): 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.
- [Application modernization](https://www.techfabric.com/cloud/modernization): We modernize applications that still earn their keep but have become expensive to change: strangling the monolith a piece at a time, replacing the data layer underneath, and shipping continuously while it happens. No eighteen-month rewrite, and no freeze on the features the business is waiting for.
- [Azure consulting](https://www.techfabric.com/cloud/azure): Your Azure roadmap has a migration, a Dynamics 365 integration and a couple of applications on it, and not enough engineers to get through them. Ours work inside your team and your tenant, and the engineers you meet at scoping are the ones who build it. We move workloads in waves you can reverse, connect Dynamics 365 and the Power Platform to the rest of the estate, and build the applications that run on it, with cost measured against the old estate every month. TechFabric is a Microsoft Solutions Partner, with designations in Data & AI, Digital & App Innovation, and Infrastructure.
- [AWS consulting](https://www.techfabric.com/cloud/aws): If you're moving a workload onto AWS and your own team is already full, or a long-running process there keeps stopping halfway, our senior engineers join yours and do the work. We migrate onto AWS, build on serverless and containers, put Databricks on AWS under the data, and run the long operations as durable workflows on Temporal, so a failed step is retried instead of left half-done. We run what we build.

## 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.