The migration stalled and nobody can say why
What we do. It is nearly always dependency discovery. We produce an honest dependency map first, then a wave plan you can argue with, before anything is moved.
AISTORSServicesCloud architecture and migration
Service 05Cloud architecture, built and handed over.
Built once, documented, handed over.
For teams standing up a new platform, leaving a data centre, or finishing a migration that stalled. Stalled migrations are almost always a dependency problem rather than a technology one. We map what actually talks to what, build the foundation as code in your own accounts, move in waves with a rollback at each one, and hand over documentation your team can rebuild from.
Book a 30-minute call
What you keep
The architecture and the code that builds it, in your own repository. If we stopped tomorrow, your team could rebuild the environment from what you already hold.
01
Who this is for
If the left column is not you, say so on the call and we will tell you what would help instead.
This is for you if
- You are standing up a new platform. Landing zones, accounts, network, identity and policy, built once and documented as it is built.
- A migration has stalled. Usually at dependency discovery rather than at the technology. That is the common case, not the exception.
- You are leaving a data centre or a hypervisor. Including VMware exits with a renewal date attached and a board asking for progress.
- You want the environment in code. Terraform, OpenTofu, Bicep, CDK or Pulumi, in your repository, rather than in somebody's console history.
- You intend to run it yourself eventually. Handover is designed in from the first week instead of negotiated at the end.
This is not for you yet if
- You want a lift and shift with no documentation. Cheaper suppliers will do that. It costs more later, and we would rather not be the reason.
- The platform decision is still political. If the choice is unresolved inside your organisation, an assessment will help you more than a build will.
- Nobody can grant access. Read-only inventory access is the minimum. Without it there is nothing honest to assess.
- You expect modernisation for free. Refactoring is proposed per workload where it repays itself, and it is priced. Anything moved unchanged is documented as moved unchanged.
- You need round-the-clock cover from day one. That is scoped separately and stated in writing, never implied as included.
02
What we fix, and how
Four things go wrong with cloud programmes. Each has a specific answer, and none of them is a platform preference.
The environment only exists in somebody's console
What we do. Everything is built as code in your repository, with policy as code and drift detection, so the environment can be rebuilt rather than archaeologically recovered.
You are locked into whoever built it
What we do. You own the code, the accounts and the runbooks, written during the build rather than promised after it. Handover is an administrative act, not a second project.
You do not know what your platform choice costs you
What we do. If you have already chosen, we build natively on your choice and put in writing what that choice costs and where it constrains you. We hold no reseller relationship, so there is no margin behind the advice.
03
What you get
Everything is built in your accounts. There is no AISTORS layer that has to keep running.
What we build
- Landing zones and account structure. Multi-account or multi-subscription design, network and connectivity, identity and access, built so one person can still explain it in a year.
- Infrastructure as code. Terraform, OpenTofu, Bicep, CDK or Pulumi, with policy as code and drift detection, because an environment nobody can rebuild is an outage waiting for a date.
- Migration assessment and wave planning. What moves, in what order, with what dependency and what rollback. Lift and shift, replatform or refactor decided per workload rather than as a doctrine.
- Database and data centre exit. Including VMware exit, where only 2 percent of affected enterprises in the survey above have moved most of their environment.
- Platform engineering. Kubernetes on EKS, AKS, GKE or DOKS, GitOps with Argo CD or Flux, CI/CD pipelines, preview environments, blue-green and canary releases.
- Reliability and operations. Observability with OpenTelemetry and Grafana, SRE practice and error budgets, incident response, disaster recovery and backup automation that has been restored from at least once.
- Cloud security. Posture management, least-privilege IAM, secrets management, network segmentation, compliance baselines, zero trust architecture.
- Documentation written during the build. Runbooks, diagrams, decision records and access registers produced as work proceeds, not assembled at the end.
What this is not
- Not a platform of ours. Everything is built in your accounts with your platform's native services. There is no AISTORS layer that has to keep running.
- Not a rewrite by default. Refactoring is proposed per workload where it pays for itself, not applied to an estate as a policy.
- Not a single-vendor answer. We hold certifications on four platforms and no reseller relationship on any, so there is no commission behind a recommendation to move.
- Not a lift and shift we will call a modernisation. If a workload is being moved unchanged, the documentation will say so.
- Not finished at go-live. An environment with no runbook and no owner regresses. That work is managed operation.
04
How it runs
The rejected options are written down at the time, because those are the ones that matter in year two.
01
Assessment and constraint mapping
Current estate, dependencies, data gravity, existing commitments, residency obligations and who you can hire. The recommendation comes from constraints, not from a feature comparison.
02
Target architecture and decision records
Landing zone, account structure, network and identity design, with a written record of each significant decision and what was rejected. The rejected options matter most in year two.
03
Foundation built as code
Landing zone, guardrails, policy as code and pipelines, all in version control from the first commit. Nothing configured by hand that will later need to be reproduced.
04
Migration in waves, with rollback
Dependency-ordered waves, each with a defined success test and a rollback path. Wave one is deliberately the least critical thing that still proves the pattern.
05
Handover and exit design
Runbooks, diagrams, access records and infrastructure as code handed over, plus a documented path for taking it fully in-house.
05
Platform native
Certified on four platforms, with no reseller relationship on any.
Azure
Landing zones, Entra ID, Bicep and Terraform, AKS, Azure Policy, Monitor and Log Analytics, Defender for Cloud, Site Recovery.
AWS
Control Tower and Organizations, IAM Identity Center, CDK and Terraform, EKS, Config and CloudTrail, CloudWatch, Well-Architected review.
Google Cloud
Organisation policy and folders, Cloud Identity, Terraform, GKE, Cloud Monitoring and Logging, Security Command Centre.
DigitalOcean
Projects and VPCs, Terraform provider, DOKS, managed databases, Spaces, plus OpenTelemetry and Grafana where the native surface is thinner.
Where a tool outside your platform's native surface is worth buying, we will name it and you will buy it directly. We take no commission and hold no reseller agreement, on any platform or any tool.
06
The evidence, if you want it
You do not need these numbers to recognise the problem. They are here because somebody in your approval chain will ask.
$1.87tn
is the forecast 2026 spend on IT services, covering application and infrastructure implementation plus managed services and IaaS. It is the largest single technology spending category.
Source: Gartner, 22 April 2026.
96%
is the forecast 2026 growth in AI-optimised IaaS spending, reaching 42 billion dollars.
Source: Gartner, 10 August 2026.
73%
of organisations operate hybrid environments. Flexera attributes rising multi-cloud adoption more to mergers, SaaS sprawl and decentralised teams than to deliberate strategy.
Source: Flexera, 2026 State of the Cloud Report; survey of more than 750 cloud decision-makers.
07
How far the migration wave has got
Almost nobody has finished. This is an unstarted migration wave, not a closing window.
Artifact / The VMware exit, as far as it has actually got
302 North American IT decision-makers
| What the survey found | Share |
|---|---|
| Reducing their VMware use | 86% |
| Concerned about future licence price increases | 88% |
| Migrating workloads to public cloud IaaS | 72% |
| Have moved 25 percent or more of their environment | 44% |
| Have moved 75 percent or more of their environment | 2% |
08
Questions we are actually asked
Which cloud should we be on?
Whichever one your constraints point to, and the constraints usually decide it before we arrive. Where the data already sits, what you have already committed to, where your identity plane lives, what your regulator will sign off and who you can hire. If you have already chosen, we build natively on your choice and tell you in writing what that choice costs you.
We are mid-way through a VMware exit and it has stalled. Can you help?
That is the common case rather than the exception. In the survey above, 44 percent had moved a quarter or more of their environment and only 2 percent had moved most of it. Stalls are usually dependency discovery rather than technology, and the first job is an honest dependency map.
Do we have to modernise everything we move?
No, and you should not. Refactoring is proposed per workload where it pays for itself. Where something is being moved unchanged, the documentation will say it was moved unchanged, so nobody two years from now mistakes it for a modernisation.
What happens if we want to bring this in-house?
It is designed for. Everything is in version control, in your accounts, with runbooks and access registers written during the build. Handover is an administrative act. We would rather you could leave than depend on us.
Can you work alongside our existing team or incumbent supplier?
Yes, and often that is the arrangement. Where an incumbent holds part of the estate we work to a documented boundary and escalation path rather than around them. We will also tell you where their work is sound, because pretending otherwise would be transparently self-serving.
How do you price a migration when the scope is uncertain at the start?
The assessment is fixed scope and produces the wave plan. Each wave is then fixed scope against that plan, and a change is re-scoped in writing rather than absorbed quietly. Investment is scoped on the introductory call.
09
Next step
Bring the estate as it actually is.
Thirty minutes, no obligation. Describe what you are running, what is forcing the change and what has already stalled. You will get a straight view of the sequence, including where you should not move anything.
- Assessment
- Fixed scope, and it produces the wave plan the later waves are scoped against.
- Investment
- Scoped on the introductory call.
- If you want it in-house afterwards
- Everything is in version control, in your accounts, with runbooks and access registers written during the build.
Book a 30-minute call
Or write to [email protected].
10
Related work
Service 09
Managed AI and cloud operations
An environment with no runbook and no owner regresses. The same four measures, every month, after go-live.
Service 06Cloud cost and FinOps
Rightsize first, commit second. What the estate costs to run once it is sitting where you put it.
Service 03Data and retrieval for AI
Pipelines, retrieval and field-level lineage on the platform you have just landed on.