Cloud Migration

Cloud migration with a rehearsed cutover and a way back.

Moving infrastructure is mostly about what nobody wrote down: hidden dependencies, data that is hard to move and costs that change shape. We inventory what runs, design the target, write it as code and rehearse the cutover and the rollback before production moves.

Scope your cloud migration →

DIRECT ANSWER

Cloud migration moves agreed workloads into a cloud, between providers or out to self-hosted infrastructure. The engagement covers inventory, target architecture, infrastructure as code, a rehearsed cutover with rollback and visibility into what the new setup costs.

Best for

Teams moving from hand-managed servers to a reproducible setup
Companies changing providers or bringing workloads back to self-hosting for cost or control

Consider another approach

Hardening an environment you plan to keep
Rewriting the application itself during the move

Decide why you are moving before deciding where

Cost, control, data location, an expiring contract or a platform that no longer fits are all valid reasons, and each one changes the target. Moves can go into a cloud, between providers or out of one to self-hosted servers. If the environment you have is fine and needs safer access and recovery, Cloud Security is the better fit. Build and release pipeline controls belong with DevSecOps. If the application itself must change architecture, plan that under Legacy Modernization; a migration that also rewrites the application doubles the risk of every step.

Turn what runs today into a target you can rebuild

Provider and platform fit are confirmed during scoping. We do not assume a universal multi-cloud service.

Inventory and dependencies

Workloads, data stores, DNS, certificates, scheduled jobs, external integrations, IP allowlists and the people who own each one.

Target architecture

Choose managed services, containers, virtual machines or self-hosted servers per workload, with the trade-offs in cost, lock-in and operating effort written down.

Infrastructure as code

Describe the target environment in version-controlled code (for example Terraform or OpenTofu) so it can be reviewed, rebuilt and handed over.

Cost visibility

Tag resources, set budgets and alerts, and compare the expected bill with the old setup. An estimate stays an estimate until real traffic runs.

Rehearse the cutover and the rollback

Each migration wave has a data transfer or sync plan, DNS and certificate steps, a change freeze if one is needed, checks that prove the new environment serves correctly and a rollback trigger with a named owner. Data written after the cutover may not flow back automatically, so the plan states how long a rollback stays possible and what it costs. Downtime windows, if any, are agreed in advance.

Illustrative acceptance: a rehearsed switch on a staging copy

In a staging copy, the team follows the cutover runbook, moves traffic to the new environment, runs the agreed functional and data checks, then switches back. The record names the runbook version, duration, data checks, issues found and limitations. This illustrates an acceptance exercise, not a customer result or a promise of zero downtime.

Plan, migrate in waves, hand over

Scope and quote each phase before work starts. Ongoing operation is a separate responsibility, not an unstated extension of the migration.

Assessment and plan
Receive the inventory, target options with trade-offs, a wave plan and a cost estimate with its assumptions.
Build and migrate
Receive the infrastructure code, migrated workloads and a verification record for each cutover.
Handover
Receive runbooks, the access model and cost reports. Who operates what afterwards is agreed explicitly; Wavect does not offer a 24/7 operations center or an uptime SLA.

Bring the bills, the architecture and someone who can approve changes

We need read access to accounts and hosting first, architecture notes, current bills, data volumes, data-location requirements, acceptable maintenance windows and a person who can approve production changes. If the move follows a provider handover, check the operational independence exercise on Software Takeover; its existing eligibility and terms apply. Ongoing care of the application after the move is Software Maintenance.

// proof

Infrastructure moves in existing engineering work

Hyperstate AI documents moving a hand-deployed, GPU-heavy single server to dockerized, orchestrated services and replacing self-managed, compute-heavy libraries with hosted alternatives. Twinsoft AI documents Terraform infrastructure built in parallel with a pilot-ready rebuild. IKB documents extending the Kubernetes cluster that runs ChirpStack, as part of the engineering inside IKB’s own build, with a complete handover to IKB’s team. None of these is a full provider-to-provider data-center move; they are adjacent infrastructure delivery, not a promise of the same outcome.

GPU Monolith → Microservices

Split a GPU-heavy monolith into orchestrated services and swapped self-hosted ML libs for scalable alternatives. Latency and cost …

Python Django OpenAI API

2 weeks To Sellable MVP

Took a vibe-coded prototype to enterprise pilot-ready, no shortcuts.

Python Flask LLMs

Complete Platform Handover

Smart City IoT for Innsbruck: extended and scaled the LoRaWAN infrastructure, evaluated and integrated multi-vendor devices, wrote …

Kubernetes LoRaWAN Docker

These are selected projects, not our full portfolio. We have shipped 100+ products since 2018.

Questions before you start

Which cloud providers do you work with?

We confirm the provider, architecture and required expertise before quoting. Common targets are AWS, Google Cloud, Azure and Hetzner, or self-hosted Docker and Kubernetes. The written scope lists the environments covered.

Will the migration cause downtime?

The plan aims to keep it as short as the data allows. Any window is agreed in advance and rehearsed on a copy. We do not promise zero downtime for every system.

Can you move us out of the cloud?

Yes. Moving to self-hosted servers can make sense for cost or control. The plan weighs that against the operating work your team takes on, such as patching, backups and hardware.

Will the migration lower our bill?

Not automatically. We estimate the new cost from the inventory and set up budgets and reports, so you can see the real bill once traffic runs. Savings are a goal to check, not a promise.

Who operates the environment after the migration?

That is agreed before the cutover. Your team, your existing provider or Wavect within an agreed scope can operate it. Hardening the new environment is a Cloud Security engagement.

Scope your cloud migration

Describe where the workloads run today, where they should go and why. Keep credentials and private system details out of the first enquiry.