Migrations that finish on the weekend they were planned for.
Assessment, migration and day-two operations across AWS, Azure and Google Cloud — with all infrastructure defined in code and a rehearsed failover before anything cuts over.
Overview
Cloud projects rarely fail technically
They fail on the third party nobody asked about. A fixed IP allowlist controlled by a partner who needs months to change it. A licence tied to a MAC address. A batch job whose owner left the company years ago. These are what turn a short migration into a long one, and every one of them is discoverable in the first week if somebody looks.
So our assessment is deliberately dull and exhaustive. By the time we quote you a cutover weekend, the sequence has been rehearsed against production data and every external dependency has a name and a date beside it.
Scope of work
What the service covers, usually in this order
Assessment, dependency mapping, a lift-or-refactor decision per workload, and a rehearsed cutover with a rollback path.
Networking, identity, backup and disaster recovery defined in Terraform and committed to your repositories.
Environment provisioning, secret management and observability, so a new environment is a pipeline run rather than a project.
Build, test and deploy pipelines that make releases uneventful, including the rollback that usually goes untested until the day it is needed.
Outcomes
What changes operationally
Deployments move into working hours, because rollback is tested and the pipeline checks what people used to check by hand.
Failover is rehearsed on a schedule and the result is written down, so your recovery time is a measurement rather than an estimate.
Tagging, budgets and a monthly review. Idle and oversized resources are identified and reported rather than quietly renewed.
Everything is in Terraform in your repositories. That is the standard we hold ourselves to, not a claim about how helpful we are.
What the assessment is looking for
Every row below has delayed a real migration. All of them surface in the first week if someone goes looking, which is the entire purpose of the assessment.
A fixed IP allowlist controlled by a partner who needs months to change it
A third-party register built in week one, with migration waves sequenced around their calendar
A licence tied to hardware, discovered during cutover
A licence audit completed before any target architecture is priced
A batch job whose owner left the company years ago
Dependency mapping from observed network traffic rather than from documentation
Disaster recovery that has never actually been tested
A full failover rehearsal on production data before the cutover window opens
The work that starts after the migration ends
Dashboards you can read, with alerts routed to named engineers.
A scheduled window with a rollback path, agreed with you in advance.
Tagging and budgets reviewed, with idle and oversized resources reported.
Failover exercised and the real recovery time written down each quarter.
All infrastructure is defined in Terraform and held in your repositories, so this arrangement is one you can end without a rebuild.
Delivery process
Assess exhaustively, rehearse, then cut over
Workload inventory, dependency mapping, licence and third-party audit, and a target architecture with costs attached.
Landing zone design, identity and network model, migration waves, and a rollback plan for each wave.
Infrastructure as code, pipeline build, non-production migration, then application migration wave by wave.
Full failover rehearsal on production data, then the planned cutover window with the rollback path live.
Managed support, monitoring, patch windows, cost review, and a quarterly disaster recovery test.
Tools and platforms
Certified on all three, incentivised by none
We hold no reseller margin that depends on which cloud you choose. For regulated Indian workloads we also deploy to private cloud and on-premise Kubernetes.
We avoid: provider-specific services that make leaving expensive; Kubernetes on projects that do not need it
See the full technology page →In practice
Legacy systems moved off ageing on-premise hardware
Infrastructure that needed constant maintenance, could not scale, and was costing more each year to keep running. We migrated the business applications to cloud, automated the deployment process, rebuilt monitoring, and put secure backup and disaster recovery in place.
cutover
Usually the one your operations team can already support, or the one your enterprise agreement already covers. Where there is no such constraint we default to AWS, or to Azure for Microsoft-heavy estates. We hold no reseller margin on any of them, so we have no commercial reason to push you either way.
Every wave has a rollback path that is built and tested before the wave runs, and the failover rehearsal happens on production data before the cutover window opens. If the criteria we agreed are not met inside the window, we roll back and reschedule. That decision is made against a written checklist rather than in the moment at two in the morning.
Yes, and most clients do, but it is a separate agreement rather than an assumption. Monitoring, patch windows, cost review and a quarterly recovery test. Because everything is defined in Terraform and held in your repositories, moving to your own team or another provider later is a decision rather than a migration.
Workloads are deployed in the region your obligations require, including backups and log retention, which is where residency requirements are most often missed. Where the requirement rules out public cloud entirely, we deploy to private cloud or on-premise Kubernetes instead.
Find out what a migration would actually cost
We run assessments as standalone paid work: current state, target architecture, and a real cost comparison against what you spend now. There is no obligation to use us for the migration, and the assessment is worth having even if you decide not to move.