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.
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.
Databricks is the platform we have gone deep on, and Temporal sits underneath the operations that must not fail. Where a system has to reach past the workspace we build on Azure, AWS, Google Cloud and Cloudflare too.
Three pieces of the same problem
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. The change never happened.
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 modernizationIf 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.