Cloud credits can buy a startup time. The harder question is what it costs to use them.
This year, Microsoft for Startups offered Twins AI $350,000 in Azure credits over two years, roughly four times our annual infrastructure spend. Taking that offer meant moving our live AI voice platform from Google Cloud to Azure.
We said yes. We planned and documented the migration beforehand. The migration work itself took two weeks, with the production switch completed over a single weekend.
The credits made the move worth doing. Our architecture made it possible. We had built the platform around containers, Kubernetes, GitOps and infrastructure as code from the beginning. That gave us a way to take the opportunity without rewriting the application.
Why we chose Azure
Two things got our attention, in this order.
First, runway. The $350,000 credit allocation covers our compute, databases, storage, observability and model spend. For an early-stage AI company, that gives us more room to invest in product and customers.
Second, model choice through Microsoft Foundry. We run real-time voice conversations, where model speed, quality and cost per minute all matter. Foundry offers a catalogue that includes Azure OpenAI and open-weight models such as Mistral, DeepSeek and Llama, with consolidated billing.
That gives us a path to choose models by task. It is also part of what comes next: bringing Azure OpenAI models and Azure AI Speech into our live call path, then evaluating open-weight models for specific jobs.
The migration started with decisions we had already made
The most important work happened before we considered Azure.
From the beginning, we ran the platform on Kubernetes, deployed through GitOps, with cloud infrastructure defined as code.
- Every service runs in a container: the web app, API, real-time voice engine and its autoscaler.
- Deployments are pull-based. Argo CD runs inside the cluster, watches a Git repository and applies the configuration it finds. Our CI pipeline does not need to know which cloud receives a deployment.
- Cloud infrastructure is declared in code, reviewed in pull requests and applied through a pipeline.
For Azure, we stood up the platform on Azure Kubernetes Service (AKS) and pointed a second GitOps controller at the same repository. The applications came up as they had before, and our build and release pipeline barely changed.
We still had infrastructure, environment configuration and data to move. But the application did not need a rewrite.
What moved where
Our use of open standards gave us a mapping for almost every Google Cloud component. Here is the before-and-after service map:
| What it does | Google Cloud | Microsoft Azure |
|---|---|---|
| Container platform | GKE | Azure Kubernetes Service (AKS) |
| Relational database | Cloud SQL for PostgreSQL | Azure Database for PostgreSQL – Flexible Server |
| Cache and job queues | Memorystore for Redis | Azure Managed Redis |
| Secrets | Secret Manager | Azure Key Vault |
| Service identity | Workload Identity | Microsoft Entra Workload ID |
| Object storage | Cloud Storage | Azure Blob Storage |
| Logs and metrics | Cloud Logging and Managed Prometheus | Azure Monitor, Log Analytics and Managed Prometheus |
| Analytics | BigQuery | Azure Data Lake Storage Gen2 and Azure Synapse |
We kept the same Kubernetes manifests, PostgreSQL version and Redis protocol. Our aim was to reproduce the platform’s existing behavior on Azure.
AI wrote most of the migration code. Our engineers owned the decisions.
Most of the migration code was written by AI coding agents, working from specifications and plans our engineers wrote. That included Azure infrastructure modules, environment configuration, data-migration scripts and runbooks.
Our team set the direction, reviewed every change and made the decisions that needed judgment. AI produced most of the code and configuration.
For a small team, that changed the economics of the project. A few engineers completed the migration work in two weeks, alongside their normal work. Our estimate is that the same project would once have required a dedicated team for a quarter.
Rehearse first. Then move production.
We migrated staging first and rehearsed the steps until they were routine. Then we moved production.
The production database migration took under half an hour. Before switching traffic, we verified that every table and every row matched on Azure.
We completed the production switch over a single weekend. Customers kept their accounts, history and integrations without having to reset passwords or reconnect a CRM. The transition went unnoticed by our customers, and performance improved after the move.
We moved what mattered, and kept what still served customers
We moved the core platform: compute, data, networking, secrets, identity and observability.
A handful of small Google services still run. Their cost is negligible, and moving them would add nothing for customers. Customer sign-in and Google Workspace integrations are examples.
Moving those services simply to claim we were “100% off” Google would have meant asking users to sign in again without giving them a benefit. We would rather spend that effort on the product.
What we gained beyond the credits
A cleaner platform. We modernized secrets, identity and observability using Azure-native services during the move.
Better performance. The platform performed better after the migration, while customers continued using it without noticing the transition.
A preview environment for every branch. The resource-group design we adopted on Azure made it simple to create a full, isolated environment for each feature branch. Every change now gets a preview link, which speeds up review and QA.
A foundation for the next model integrations. Next, we plan to bring Azure OpenAI models and Azure AI Speech into the live call path. We will also evaluate open-weight models from the Foundry catalogue for specific tasks, using the same credits and consolidated bill.
What I would tell another founder
- Build portability in early. For us, containers, GitOps and infrastructure as code were relatively inexpensive decisions at the start. They became much more valuable when an opportunity to move appeared.
- Treat credits as an option you can exercise. This offer was worth taking because the migration work took two weeks, rather than the quarters we estimate a less portable approach could have required.
- Give agents clear work and engineers clear ownership. Write good specifications. Let coding agents generate infrastructure and scripts, and keep engineers responsible for review and judgment.
- Rehearse on staging. By the time we touched production, we had already run every step at least once.
- Move what matters to customers. Focus the work on the platform and the customer experience. Keep useful services when moving them offers no benefit.
The credits created the opportunity. Being able to move made it useful.
Thank you, Microsoft for Startups
Thank you to the Microsoft for Startups team for backing Twins AI. The credits give us runway. Foundry gives us room to explore the next generation of our voice agents and choose models for the jobs they do best.
