Rebuilding a Live AI Platform on a Second Cloud

A multi-service, AI-driven SaaS platform had been running in production on one hyperscaler long enough to have real users, settled release cadences and operational habits built around it. It was rebuilt in full on a second hyperscaler in a European region, entirely through reusable infrastructure as code.

The interesting part is not that it moved. It is what the estate was made of. Close to half of it was managed AI: a hosted large language model service, a managed search and retrieval service, speech to text, and text and image embedding models. Those were not background infrastructure. They were the product.

That distinction shaped the plan. A database migration can be proved correct by comparing schemas, row counts, indexes, roles and query plans. A retrieval layer cannot. If relevance drops by a fifth, nothing fires and the first real signal is a slow decline in how much users trust the answers they get.

A European AI SaaS platform, live and mature rather than greenfield, organized into six functional layers: edge and security, containerized application workloads, database and storage, AI services, data and machine learning services, and security and operations.

Inside the application layer, three services deployed independently within a single container environment, each with its own release cadence and operational footprint. That separation had been a product decision made years earlier for reasons that had nothing to do with cloud portability, and it turned out to be the most valuable property of the existing design.

The client, the platform vendors, the region and the product services are not named, at the client’s request.

The brief pulled in three directions at once, and the hardest of them had no alarm attached to it.

The AI stack could not be lifted. The hosted model service, managed search, speech to text and both embedding models were woven into how each application service behaved. Reproducing the platform meant re-establishing that behavior on a different provider, under a different API surface, with different model families underneath.

The system stayed live throughout, which ruled out any approach depending on a maintenance window from the first day. And delivery could not pause: the build and deploy pipeline was itself part of what had to migrate, not something to reconnect once the infrastructure landed.

Five things had to hold at once, and they were not independent of each other. Users depended on all three services daily, so there was no acceptable downtime to migrate into. A poorly reproduced embedding or retrieval architecture degrades relevance quietly, which is arguably worse than an outage because an outage tells you it happened. If the new build surfaced problems late, the organization needed a real way back rather than a rushed reconstruction of an environment already decommissioned. The new network design had to match or exceed the isolation already around the application and database tiers, because migrations regress posture quietly in the name of speed and it is rarely noticed until an audit. And a migration that freezes the roadmap for a quarter carries a cost that never appears in the migration budget.

Kainskep ran the migration end to end, from assessment through cutover and pipeline handover. That included assessing the existing estate across all six layers as a set of behaviors to preserve rather than a resource inventory to copy; designing the target architecture across two availability zones and encoding it entirely in reusable modules parameterized per environment; re-platforming all three application services; owning the AI and data workstream and the rebuilt retrieval architecture; executing the database migration and its validation; running the phased cutover; and keeping the original environment intact as a live rollback path.

The three-service structure carried over with no loss of application or AI capability. Application and database tiers hold no direct internet exposure, with all public traffic passing through the web application firewall and load balancer and administrative access separated through single sign-on and VPN. Reusable modules now cover the entire environment, closing the drift that had accumulated between environments. No maintenance window was required at any point, and the DNS cutover stayed reversible.

What is not published here is any measure of whether retrieval quality changed. The rebuild was designed to preserve behavior and was reviewed on output, but a before-and-after relevance metric was not produced, and inventing one would defeat the point of the section that says so.